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The Universities Space Research Association (USRA), under sponsorship from the NASA 
Office of Space Science and Applications, conducted a Telescience Testbed Pilot Program. 
Fifteen universities, under subcontract to USRA, conducted various scientific experiments 
using advanced computer and communications technologies. The goals of this pilot program 
were to develop technical and programmatic recommendations for the use of rapid- 
prototyping testbeds as a means for addressing critical issues in the design of the 
information system of the Space Station Freedom era. 

This is the final report for the Pilot Program. It consists of three volumes. Volume I provides 
an Executive Summary. Volume II contains the integrated results of the program. Volume III 
provides summaries of each of the testbed activities. 
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Section 1 

Introduction and Summary 


1.1 Introduction and Document Overview 

Space Station Freedom (henceforth referred to as Space Station) and its associated 
laboratories, coupled with the availability of new computing and communications 
technologies, have the potential for significantly enhancing scientific research. To assure that 
this potential is met, scientists and managers associated with the Space Station program 
must gain significant experience with the use of these technologies for scientific research, 
and this experience must be fed into the development process for Space Station. The SESAC 
Task Force on the Scientific Uses of Space Station (TFSUSS) has used the word telescience 
to refer to the concept in which interactive high-performance telecommunication links are 
used to link the space-based laboratories and facilities, the on-orbit crew, and 
geographically dispersed ground-based investigator groups. Instead of being a remote 
outpost, Space Station is, rather, an accessible and integral part of the research 
infrastructure . 1 

The Universities Space Research Association (USRA), under sponsorship from the 
NASA Office of Space Science and Applications, has conducted a Telescience Testbed Pilot 
Program (TTPP), aimed at developing the experience base to deal with issues in the design 
of the future information system of the Space Station era. The specific goals of this pilot 
program were to: 

• Demonstrate that the user-oriented rapid-prototyping testbed approach is a 
viable means for identifying and addressing the critical issues in design and 
specification for the Space Station Information System (SSIS) and the Science 
and Applications Information System (SAIS), thereby assuring that these 
systems will satisfy the needs of scientists for an information system in the 
Space Station era, 

• Develop technical and programmatic recommendations for the conduct of such a 
testbed, and 

• Develop initial recommendations for the SSIS and SAIS to be factored into the 
design and specification of those systems. 

To accomplish these goals, fifteen universities conducted various scientific experiments 
under subcontract to USRA. Each one of these experimental testbeds share the 
characteristic of attempting to apply new technologies and science operations concepts to 
ongoing scientific activities. Through this process, new understanding and experience was 
gained about system architectures, concepts, and technologies required to support future 
scientific modes of operation. 


1. Task Force for Scientific Uses of the Space Station, 1986 Summer Study. 
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This report contains the results of the Telescience Testbed Pilot Program. The report is 
in three volumes. Volume I is the Executive Summary. Volume II (this volume) contains the 
integrated results. Section 1 is an introduction and summary, providing background on the 
program and highlights of the program results (duplicating much of the Executive Summary.). 
Section 2 describes the program, summarizing the various testbed experiments and the 
programmatic approach. Section 3 summarizes the results on a discipline by discipline basis, 
highlighting the lessons learned for each discipline. Section 4 integrates these results across 
disciplines, summarizing the lessons learned overall. Volume III contains summaries of each 
of the experiments conducted under the university subcontracts. Further details of these 
experiments are contained in the various scientific and technical reports published by the 
researchers. 

1.2 Highlights of Results 

Sections 3 and 4 of Volume II contain the results of the TTPP. Here, we provide 
highlights of these results. Some of these observations and results were general and came 
from integrated TTPP experience. Others were developed in the context of a specific 
scientific discipline and could not be generalized, either because there was insufficient 
experience in the other disciplines or there were differences between the discipline 
requirements. In cases where results were from specific testbed activities, the universities 
are cited for cross-referencing to Volume m. 

1.2.1. General Technical Results 

A number of results in teledesign, teleoperations, teleanalysis and infrastructure were 
found to apply across the several disciplines. In the area of teledesign, the focus was on the 
remote development and debugging of software. 

• Remote debugging of instrument software was demonstrated to be both 
possible and effective. On-line access to a variety of common software tools 
was shown to be important and feasible. 

• A need was identified for trade-off studies and simulation tools to complement 
testbedding in the design phases. 

• , Ada was demonstrated to be a useful and acceptable high level language for the 

design and development of real-time systems. 

Teleoperations covers the spectrum from making small instrument adjustments to 
optimize data taking through the full interactive operations required for Life and Microgravity 
Sciences. Safe operations in both cases were investigated using transaction management 
plus interlock concepts. A number of common results and conclusions were demonstrated in 
the area of teleoperations. 

• The benefit of using a common workstation for access to multiple instruments 
was demonstrated. The experience with OASIS indicated that it is possible for 
groups from different disciplines to use a common teleoperations workstation. 
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• Interconnected facilities were shown to allow multiple researchers to collaborate 
on experiments, e.g. have an expert at one site available for troubleshooting 
during experiments being conducted at other sites with other researchers. 

(SAO) 

• All of the TTPP sites chose either Sun or microVAX workstations along with 
either Unix or VMS operating systems as their main workstations, 
supplemented by PC-AT compatibles and Macs. This class of hardware and 
software was found to be adequate for teleoperations. 

• Teleoperations was shown to lead to improved productivity by: 1) permitting the 
assembly of required resources with minimal travel costs and equipment 
shipment, 2) enlarging access to space instruments and scientific data, 3) 
permitting rapid access to flight data, and 4) permitting direct Pi/crew interaction. 

General teleanalysis results included the following: 

• A number of the research groups found minimal need for analysis during 
operations, because they were simply too busy. 

• Viewing data requires screen refresh on order of .1 to 1 minute, almost 
irrespective of data characteristics. The locating of remote data was supported 
acceptably through 9600 bps access with subsequent file transfer through the 
Internet. 

• Image compression methods for preserving important information while reducing 
bandwidth are important. The information needed to preserve varies between 
applications, and therefore so do the appropriate algorithms. Experimentation 
with various algorithms indicate that such techniques have potential. 

• There is an important niche for D3M-PC compatible and Mac 13 class 
workstations, coupled to larger host computers through LANs and dial-up 
circuits. This lower cost alternative needs further exploration. 

• Although connectivity to data sources is a primary aspect of teleanalysis, the 
additional ability to exchange ideas, techniques, and software among research 
collaborators proved to be equally important. 

Infrastructure results focussed on communication requirements and workstation 
characteristics. 

• Space to ground communications bandwidth requirements for many of the 
experiments were dominated by the need for video feedback. Downlink video 
with Pi-adjustable frame rate, resolution, and gray scale is required out to the 
PI remote site. Adjustment capability is required by the PI to obtain the “best 
picture” within the currently available bandwidth. Uplink video is required to 
support “coaching.” 
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• Communication requirements for low-latency transmission appear to be for high 
peak rates but low average rates. Such a requirement is well suited to packet 
switching, but the current networks have proved to be inadequate. 

• Participants found that workstation interface standardization was a more 
important concern than the exact hardware/software configuration used. This 
led to the conclusion that selection of commercial off-the-shelf 
hardware/software configurations may be feasible and desirable for many 
purposes. 

• The timing cycle for NASA/universities/institutions was longer than the one- 
year TTPP program itself, thereby limiting the ability to install the required 
infrastructure during this limited program. 

• Exchange of information is hampered by groups using different text/graphics 
formats. 

• TAE+ was found to provide a good set of tools for prototyping the user interface 
for workstations. 

• The need was identified for tools to support real-time group collaboration (e.g. 
teleconferencing). One possibility suggested was to incorporate NASA’s 
audio/video teleconferencing system into the testbed to support interaction 
between groups and to evaluate its effectiveness for scientific collaboration. 

1.2.2. Astronomy 

The participating astronomy and astrophysics researchers noted that theirs is an 
observational science. Unlike several of the other disciplines (particularly life and 
microgravity sciences), the subject of the typical experiment cannot be modified by the 
researcher. This characteristic heavily flavors the nature of telescience for astronomy, driving 
towards monitoring of the observations and the ability to access data quickly and “fine tune” 
the observing instruments. Fine tuning can greatly enhance the quality of the data obtained. 

Thus, teleoperations for astronomy involves the real-time control of observations and 
real-time access to data. Experiments conducted under the TTPP led to the following results 
and conclusions: 

• Fully autonomous operation is often more costly than teleoperation due to the 
need for higher instrument precision. 

• Scientific productivity is improved through access to real-time data from the 
researchers’ home institutions. (SAO, MIT/KSC, University of Colorado, 
University of Arizona) 

• The instrument design process can be improved by incorporating the network 
interface into instrument design from the start, allowing among other things that 
required software updates be done remotely. (SAO, UCB, Arizona) 
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• Data compression holds significant promise for permitting teleoperations of 
telescopes while keeping to available bandwidths. CCD images typically 
require minutes of integration, thereby reducing the required rate of image 
transmission. A possible exception is solar observation of dynamic processes. 

An image compression technique was demonstrated that reduced the required 
data rate from 8 bits/pixel to .015 bits/pixel. (Arizona) 

Teleanalysis is a prime requirement for the astronomy and astrophysics community, 
permitting databases to be accessed remotely. 

• Poor connectivity and performance of existing networks made tests of such 
remote access difficult. (Arizona) 

• The utility of a standard data analysis environment (IRAF, AIPS, FITS) was 
validated through several of the testbed activities. 

Support of the required teleoperations and teleanalysis environments required adequate 
communications. The experimenters found that: 

• 9600 bps links with five second delay are adequate for normal operations (not 
including video/images). (Arizona) Many of the participants strongly expressed 
the need for occasional use of a “priority channel” for command and control with 
overall round trip time delay of less than one second. While somewhat longer 
delays can be tolerated, this requires use of special techniques which rapidly 
become more complicated and less effective. 

• Network latencies of more than 30 seconds results in remote operators 
resubmitting requests. Therefore, there is a need to keep latency down and 
make the system tolerant of repeated requests. (Colorado) 

• Current networks (e.g. SPAN and Internet) are adequate for electronic mail but 
inadequate for most other functions. Typical transfer rates for files across the 
Internet were approximately 1 kbps. (SAO, Arizona) 

• The Astronomy community found a need for standards (ranging from networking, 
e.g. Internet, through data format standards, e.g. FITS), and demonstrated their 
utility. 

1.2.3. Earth Sciences 

Earth Science participants found that their awareness of telescience possibilities plus 
access to telescience tools had significant positive effects on the conduct of their research. In 
the area of teledesign, distributed software development was an area of concern. Specific 
results were the following: 

• Duplicate software environments are required to support collaborative 
development. Moving software and software environments between sites was 
found to be more difficult than anticipated. 
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• A shared 56 kbps network (similar to the current SPAN and Internet) was found 
to be adequate for remote debugging of software. 

Teleoperations for earth sciences focussed on remote monitoring and control of sensor 
platforms, and the conduct of campaign-style experiments involving researchers at multiple 
locations conducting observations using multiple sensors. It was found that: 

• There was a de facto standardization on OASIS for remote operations, and 
OASIS functionality was found to be basically satisfactory even though OASIS 
was developed for a different discipline. A need for a library of software tools to 
support teleoperations was identified. 

• Due to time and technology limitations, the campaign experiments conducted 
under the TTPP were designed to require only electronic mail for coordination. 
Future campaign experiments are expected to require more sophisticated 
collaboration technology. 

As in astronomy, earth science research relies heavily on access to remote data sets 
for analysis. The experimenters found that: 

• There is a need for secure database access methods, and techniques for 
avoiding conflicts between real-time system operations and retrospective 
analysis. (Wisconsin, Purdue, UCSB) 

• The testbed experience supported the need for high-level catalog and directory 
services for earth science datasets. Standards for data description are more 
important than standards for data formats. 

Network access was required throughout the science process, from design through 
operations to analysis. 

• The need was identified for verification of file transfer, analogous to return 
receipt for mail. There is also a need for the ability (currently available in the Z- 
modem protocol) to recover from communications outages in the middle of file 
transfers, to permit transfer of large files. 

• Current networks were found to be inadequate, with too many dropped sessions 
for file transfers. The 9600 bps data rate was not sufficient for interactive 
remote display of bit-mapped graphic images. The 30 second round trip delays 
sometimes encountered were also found to be unacceptable. 

1.2.4. Life Sciences 

Life sciences research is different from other disciplines in that the astronauts may be 
both subjects and experimenters. Life sciences research program often finds itself 
constrained by limitations in communication and control, limited available crew time, and time 
delays in data availability. 
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Teleoperations for life sciences involved both the monitoring and control of remote 
experiments and the interaction between ground-based Pis and the crew in the conduct of 
such experiments. 

• Coaching techniques were found to be very effective in supporting Pl/crew 
interaction during experiments. An crew “open mike” approach, allowing 
effective monitoring by the PI, was most effective. Workstations incorporating 
computer-supported collaboration tools were helpful. (MIT/KSC) Pl/crew 
interaction was facilitated through use of medium resolution, wide field of view 
color TV. (Ames) 

• Pis require real-time monitoring data. This allows for more effective use of crew 
time. (MTT/KSC, Arizona, Colorado) 

• Data compression for video can be helpful. It can be lossy for monitoring/quick- 
look, but needs to be lossless for eventual analysis. Command/telemetry data 
for the specific experiments conducted did not need to be compressed due to 
their inherendy low data rates (<9600 bps, average few hundred bps). 

(MIT/KSC, Arizona) 

• Operations management technologies (including command interlocking and 
reaction control) were shown to work in protecting the health and safety of both 
experiments and space subsystems. (University of Colorado) 

The life sciences experiments led to a number of results concerning requirements for 
communications and other infrastructure, primarily in support of teleoperations. 

• Ada was an excellent choice as a standard programming language for life 
sciences telescience applications. A clear understanding and documentation of 
interfaces between distributed software components is required. (Arizona, 
Colorado) 

• The functionality of OASIS (capabilities and ease of customizing) proved 
essential for teleoperations for life sciences. It needs to be enhanced for speed, 
communication capabilities, and use of a TAE+ type of front end. (Colorado) 

• CCSDS SFDU’s were found to be adequate for support of teleoperation data 
exchange for life sciences. The requirement for standard data structures for data 
interchange was identified, and CCSDS standards recommended. (Arizona, 
Colorado) 

• For the experiments conducted, time delays for remote coaching between audio 
and video of 1-3 seconds were acceptable. Delays of 30 seconds were 
unacceptable. (MIT/KSC) Remote robotic control required delays of less than 
one second. This is a concern given propagation delays, and methods for coping 
with such delays must be developed. (Arizona) 

• When observing crew activities under conditions of reduced video bit rate in the 
particular experiments investigated. Pis typically traded off color and temporal 
resolution (frame rate) in order to obtain at least 4-5 bits of grey scale and the 
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maximum available spatial resolution. Although this suggests that slow scan 
video may be acceptable for many activity monitoring tasks, the Pis noted that 
there were times when bursts of full rate video were essential or helpful. 
(MIT/KSC) 

• Data dropouts of less than one second were tolerable. Recovery of lost data 
was of little utility for real-time data monitoring. (MIT/KSC) 

• SPAN and local nets were inadequate for experiments conducted jointly with 
JSC due to excessive delay and packet loss (caused by excessive network 
traffic). The conduct of experiments was found to require high-priority 
commitment from communication suppliers or the provision of dedicated virtual 
circuits. (MIT/KSC) 

• Standard “user-friendly” workstation interfaces were shown to be very 
effective in improving productivity. The Macintosh interface was shown to be 
useful in prototyping. X- windows was an acceptable windowing standard for 
development of a PI workstation. (MIT/KSC, Ames, Colorado) 

1.2.5. Microgravity Sciences 

Researchers in the Microgravity Sciences found that the key contribution to productivity 
was via “rapid feedback,” being able to obtain quick-look results rapidly by monitoring data 
during the conduct of the remote experiment.. The major results obtained regarding 
teleoperations were that: 

• Control signals require internal error checking and correction and probably a 
“limit-switch” type of mechanical protection. (RPI) 

• When crew assistance is required, a minimum of one dedicated direct voice 
channel is required during the period of crew involvement. 

• Not all microgravity experiments are amenable to teleoperations. 

1.2.6. Programmatics 

One of the primary purposes of the TTPP (the “pilot program” aspect) was to validate 
the approach of having multiple universities collaborate through a set of user-oriented rapid- 
prototyping testbeds for the purpose of investigating critical issues in the design of the 
information system of the Space Station Freedom era. Part of this investigation was into the 
appropriate mechanisms and approaches for conducting such a program. A number of lessons 
were learned regarding these programmatic aspects: 

• The Astronomy community found the use of networking, particularly electronic 
mail, highly productive. They used the network heavily for coordination and 
preparation of area reports, finding the technique highly satisfactory and 
effective. 
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• Life sciences participants found that coordination between participants required 
four different communication levels: project definition documents, telephone, 
electronic mail, and site visits. 

• The TTPP contractual arrangement, using a prime contract with USRA and 
subcontracts with universities, worked extremely well. 

• Critical issues need to be identified prior to the selection of individual 
testbedding activities. A separate activity involving requirements integration, 
architecture definition, etc., is required and should be carefully coordinated with 
testbedding activities, driving the selection of critical issues and approaches and 
integrating results. 

• There is a need to develop a long-term program to reduce the impact of aspects 
such as funding delays, delays in installing communications, and delays in 
procuring equipment. It typically takes 2-3 years from proposal to results. 

• Campaign experiments (involving multiple instruments and organizations) need 
to be more carefully coordinated and planned, with attention paid to finding the 
science content and managing expectations. It is too easy to try to tackle too 
large a problem for a rapid-prototyping approach. 

• Similarly, incorporation of state-of-the-art technology takes different time 
scales for different activities. There is a need for a project structure that allows 
for differing time schedules of different testbeds. 

• The combination of electronic mail, electronic reporting, electronic mailing lists, 
and regular program meetings and briefings was effective in coordinating and 
conducting the program. Guidelines are needed to avoid excessive mail. 
Appropriate facilities and staffing are needed to maintain electronic mailing 
lists. Summary reports by the USRA program manager with pointers to detailed 
reports would be helpful in reducing information overload. 

• Databases need to be designed to manage electronic communications with 
priority schemes and extensive cross-referencing 
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Section 2 

Program Description 

There are a large number of issues that need to be resolved through the use of 
multidisciplinary teams of university scientists and technologists working together in a rapid- 
prototyping user-oriented testbed environment. Examples of such issues are the following.: 

• What is the impact of the distribution of users on how the system architecture 
should be designed? 

• How can access to the variety of required resources be provided in a 
coordinated manner? 

• What is the required user interface to allow scientists to gain access to the 
resources in a consistent way? 

• What is the impact of reduced or intermittent communications? 

• What is the interaction of remote control and autonomous operation of an 
experiment? 

• How should the planning and scheduling of multiple activities using common and 
shared resources be implemented? 

• What are the requirements for authentication, access control, and security, and 
how can they be best accommodated? 

• What are the required characteristics of the underlying communications 
networks and what are the supporting networking technologies to be used? 

The TTPP began the process of resolving these questions, both investigating technical 
issues and exploring the feasibility and approach to such a testbed. The goal of the 
testbedding program is to allow scientists to interact with potential space station 
technologies in a manner that will allow resolution of design and specification questions 
without having to wait until space station hardware is available. 

In the TTPP, experiments were carried out in the context of the four generally defined 
space science disciplines of primary interest for the Space Station: Astronomy and 
Astrophysics, Earth Systems Sciences, Life Sciences, Microgravity Sciences, and Space 
Physics. For each of the testbeds, telecommunications infrastructures were established 
based on technologies representative of those available for use in the SSIS. Scientific 
research and experiments was then conducted using these telescience-relevant 
technologies. 

An important methodology employed in the program was that of rapid-prototyping. As 
deficiencies, required enhancements, or new and relevant technologies surfaced, they were 
inserted into one or more of the testbeds for evaluation. The effectiveness of the various 
telescience technologies were then evaluated on an ongoing basis, and the infrastructure 
adjusted accordingly. 
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We now give a summary description of the various testbedding activities. Complete 
descriptions may be found in Volume III of this report (containing short descriptions of each 
experiment conducted under the program) as well as the numerous technical papers and 
reports written by the program participants and listed in the TTPP Bibliography (Appendix 
B). We then describe the programmatic approach used to manage and coordinate the large 
number of activities involved. 

2.1 Summary of Testbed Activities 

Fifteen universities together with eight NASA centers worked together in the four 
space science disciplines. In each case, a variety of specific experiments (described in 
Volume ID) were performed. In addition, several testbeds were selected that span a number 
of disciplines and represent technologies that have potential of significant application to 
telescience. In all cases, the experiments were selected because they represented 
emulations of one or more aspects of conducting space science and allowed experimental 
exploration of the critical issues involved in the information systems for such research. 

For each discipline, we list the universities and centers involved followed by a brief 
description of the areas of research explored. 

Q 

2.1.1. Astronomy and Astrophysics 

California Institute of Technology 
Cornell University 

Massachusetts Institute of Technology 
University of Arizona 
University of Colorado 
University of California, Berkeley 

NASA Goddard Space Flight Center 
NASA Ames Research Center 
Jet Propulsion Laboratory 

In the space station era, astronomical research will increasingly demand distributed 
user teams for operations planning, resource management, data reduction and integration, 
and archiving. In addition, the creation, simulation, and adaptation of hardware and software 
is certain to benefit from the use of design tools that encourage intergroup communication 
and communications protocols. To further these objectives, a variety of experiments were 
performed that focused on the detailed planning, operation, data analysis, hardware design, 
and software development that support contemporary astronomical research. 

Specific university activities were as follows: 

MIT investigated the remote operation of a telescope at Wallace Observatory using 
a high bandwidth (Tl) link and dissemination of data on a campus-wide Project 
Athena network. 


February 1989 


RIACS TR 89.8 


H-12 



TTPP Final Report V. n/Program Results 


Sect. 2/Program Description 


University of Arizona conducted investigated teleoperation of a forerunner of the 
Astrometric Telescope Facility, which will be an attached payload for Space 
Station. They also participated in the SERTF activity, described below. 

University of California at Berkeley extended control and simulation systems 

developed for the Extreme Ultraviolet Explorer (EUVE) to evaluate techniques 
for remote instrument control over local and wide area networks. Distributed 
development environments in use at Berkeley are being extended to facilitate 
coordinated development by cooperating institutions. 

University of Colorado studied distributed and interactive operation of an astronomy 
telescope and its instrumentation at a remote ground observatory, addressing a 
range of teleoperations issues. 

The Space Infrared Telescope Facility (SIRTF) team, consisting of Cornell 

University, Smithsonian Astrophysics Observatory, CalTech, and University of 
Arizona, investigated several issues regarding telescience applied to a Space- 
based astronomical facility. They evaluated distributed versus resource- 
centered models for development (teledesign) and remote access. The ability to 
interchange analysis software and perform in conference mode for design, 
operations and analysis was evaluated. University of Arizona has a special 
interest in remote control and operations of a ground-based telescope to 
evaluate feasible degrees of automation, allowable time delays, necessary crew 
intervention, error control and feasible data compression schemes. Cornell 
University investigated trade-offs between on-line local processing and 
processing at the users’ home location as well as investigating the feasibility of 
establishing standard formats and analysis techniques. Smithsonian 
Astrophysical Observatory is using remote operation of Mt. Hopkins telescope 
to evaluate data transmission and dissemination options. 

2.1.2. Earth System Sciences 

Purdue University 

University of California, Santa Barbara 
University of Colorado 
University of Michigan 
University of Wisconsin 

NASA Goddard Space Flight Center 
Jet Propulsion Laboratory 

The area of Earth System Sciences encompasses the fields of Remote Sensing, 
Aeronomy, Solar-Terrestrial Physics and Space Plasma Physics. The science goals of the 
experiments included multidisciplinary investigations of the near Earth environment, support 
for coordinated science campaigns and cooperative data analysis. The possible telescience 
studies covered most of the key issues previously described, and focused on the operational 
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requirements of a distributed user community, the use and interaction with both real-time 
and archived distributed data sources, the coordination of data collection in campaign mode 
and the evaluation of standards for data transfer, communications and commanding. 

Specific university activities were as follows: 

Purdue University evaluated teleanalysis concepts using the Purdue Field Spectral 
Database accessed by a variety of small computers. It also investigated 
methods for conducting campaign style experiments and computer data security 
issues. 

University of Colorado in coordination with UC Santa Barbara, Wisconsin, Purdue 
and Michigan, used the interactive control opportunities and the science 
database from the Solar Mesosphere Explorer Mission to investigate 
coordinated teleoperations and teleanalysis issues. 

University of California, Santa Barbara explored teleanalysis of large dynamic data 
sets for earth sciences. This investigation includes the test and evaluation of 
data interchange standards and knowledge based techniques for assisting 
remote access. 

University of Michigan investigated teleoperations of a Fabry-Perot Spectrometer 
combining human with autonomous control, forward simulation techniques to 
support telerobotics, and the effects of varying time delays in the control loop. 

University of Wisconsin developed a bridge from NSFnet to McIDAS, allowing any 
TTPP participant with access to NSFnet to acquire existing meteorological 
products from McIDAS. 

2.1.3. Life Sciences 

University of Arizona 

University of Colorado 

Massachusetts Institute of Technology 

Stanford University 

NASA Johnson Space Center 

NASA Kennedy Space Center 

NASA Ames Research Center 

The life sciences testbeds addressed the issues involved in space life science 
investigations where the interactions are primarily between a ground-based PI and a remote 
crew member performing an experiment. The importance of interactive communications during 
life science experiments has been amply demonstrated on past shuttle missions. The 
emergence of the long-term space station flights, where the crew cannot be expected to be 
intensively trained in each experiment, will make this interaction even more necessary. 

Specific university activities were as follows: 
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University of Arizona developed systems and software for remote fluid handling in 
support of microgravity and life sciences. 

University of Colorado developed and demonstrated tele operations capabilities for 
the remote operation of a life science glovebox experiment. 

MIT is conducting conducted a Remote Life Sciences Operation testbed using the 
KSC sled with multi-media tests and evaluation of real video needs and 
implementation options. 

2.1.4. Microgravity Sciences 

Rensselaer Polytechnic Institute 
University of Arizona 

NASA Lewis Research Center 
Jet Propulsion Lab 

The microgravity sciences testbed will encompassed low gravity research in a variety 
of materials science areas including metals and alloys, electronic materials, glasses and 
ceramics, and electrophoretic peptide separations. Space experiments already been carried 
out in these areas, and those currently planned have frequently been constrained by the 
requirement of highly autonomous operation. Telescience offers the promise of allowing the 
investigator to observe the experiment progress from a terminal in his earth laboratory and 
to make fine adjustments in the equipment, change experimental parameters, modify 
protocols, and deal with unexpected developments. 

Specific university activities were as follows: 

Rensselaer Polytechnic Institute investigated the level of communications capability 
required to successfully perform remote controlled materials processing 
experiments of the Space Station era. Three different types of experiments were 
tried with the cooperation of the Microgravity Materials Science Laboratory at 
Lewis Research Center. 

University of Arizona developed systems and software for remote fluid handling in 
support of microgravity and life sciences. 

2.1.5. Telescience Technologies 

University of Arizona 

University of California, Santa Barbara 

University of Colorado 

University of Michigan 

RIACS 

Stanford University 
Ames Research Center 
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The experiments described above were designed to identify the requirements for 
carrying out science in the space station era and the role that advanced technologies can play 
in that science. It can be seen from the descriptions that a number of technologies have roles 
to play in multiple disciplines. 

In addition, there are several technology areas where it is desirable to develop and 
demonstrate particular capabilities applicable to a variety of disciplines and make them 
available to those science communities. The following is a description of the university 
activities to investigate these underlying technologies. 

University of Arizona explored issues in robotics applied to both fluid handling and 
operations of astronomical observatories. 

University of California, Santa Barbara, investigated techniques for users to interact 
with large datasets at remote sites through a browsing capability. 

University of Colorado prototyped and evaluated onboard operations management 
concepts to verify that teleoperations can function safely without command pre- 
checking. They cooperated with a number of sites in evaluating the Operations 
and Science Instrument Support (OASIS) software package, and ported OASIS 
to the Sun workstation as a test of the portability of an operational real-time 
system written in Ada. They also investigated the use of packet telemetry, 
packet commands, and SFDU’s in the Space Station environment. 

University of Michigan has explored the role of expert systems in supporting remote 
coaching in both an on-line and off-line mode. 

RIACS integrated various networking and local computing capabilities into a 
telescience workstation environment (TeleWEn), intended to provide a local 
computing environment for telescience. RIACS also collaborated with Ames 
Research Center in investigating experiment operation using computer- 
supported coaching. RIACS, again in collaboration with Ames, investigated the 
utility of networking and electronic mail in supporting a large distributed group 
activity (the TTPP itself). 

Stanford University experimented with a model Remote Science Operations Center 
linked to GSFC, JSC and MSFC using real data from Spacelab 2 to test 
multimedia Telescience workstations and simulate remote control, monitoring 
and multi-media conferencing. 

2.2 Programmatic Activities 

As discussed in Section 1, one of the major reasons for conducting the TTPP was to 
validate the user-oriented rapid-prototyping testbed approach to involving the scientific 
users in the development process for large facilities such as Space Station. Because the 
TTPP was a pilot program, careful attention was paid to the programmatic approach to 
assure that the lessons learned could be applied to any follow-on program. We now 
describe the sequence of activities that took place. 
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Proposal Submission 

Based on the recommendations of the Task Force for Scientific Uses of the Space 
Station (TFSUSS), 1 2 the recommendations of an expert panel convened to review the 
mechanisms for users to interact with the Space Station development process,- and 
recommendations from a number of advisory panels, NASA issued a Request for Proposals 
on February 10, 1987. 3 Appendix C provides the Statement of Work from that RFP. 

Prior to the issuance of the RFP, a number of scientists from around the country had 
been discussing a collaboration to address a number of issues through a rapid-prototyping 
testbed environment. USRA was requested by this group to assist in organizing and 
submitting a proposal to NASA. Thus, when the RFP was issued, this community was well 
prepared to be responsive to the NASA requirement. The proposal (the text of which is 
available as a technical report 4 ) outlines a program involving roughly 8-10 universities 
conducting a number of testbeds with USRA acting as technical manager and subcontracting 
to the universities. The proposal also outlines a management plan calling for proposals to be 
submitted by universities and selected by USRA with the approval of NASA, using a 
Proposal Review Group, again selected by USRA with the approval of NASA. This proposal, 
submitted on March 12, 1987, was selected by NASA with a contract award made on April 
28,1987. 

Subcontractor Selection 

The first required step in the process of awarding the subcontracts was to develop a 
subcontract acquisition plan and have it approved by NASA. This was done rapidly to 
expedite subcontract award. This plan is included as Appendix D. The plan called for an 
Announcement of Opportunity (AO) to be published by USRA, included as Attachement 1 to 
Appendix D. 

The selection criteria were included in the AO, and were focussed on the philosophy of 
conducting a number of experimental testbeds that would achieve a number of objectives 
simultaneously: 

1. Emulate some aspect of the conduct of science as anticipated for the Space 
Station era, thereby investigating critical issues in the design of the Space 
Station Information System as they affect scientific research. 

2. Allow exploration of the application technologies that represent the level of 
functionality expected in the Space Station era. 

3. Be scientifically sound research in their own right. 


1. Task Force for Scientific Uses of the Space Station, 1986 Summer Study. 

2. Leiner, B.M., Strategy for User Involvement in SSIS Design, RIACS TR 86.19, October 1988. 

3. NASA Solicitation No. RFP 10-3911 1/HWC. 

4. Leiner, B.M., Telescience Testbed Pilot Program, RIACS TR 87.12, May 1987. 


February 1989 


RIACS TR 89.8 


H-17 



TTPP Final Report V. n/Program Results 


Sect. 2/Program Description 


The AO was mailed in May 1987 and the Proposal Review Group convened on June 2 - 
3, 1987 to review the proposals and recommend selection of universities for subcontract. 
Based on their recommendations, USRA selected and submitted for NASA approval 15 
university proposals. Over the period June through November, the various subcontracts 
were approved by NASA and put in place. 

Coordination Mechanisms 

Once the participants were selected, a number of mechanisms were put in place for 
coordination and management of the program. These included electronic mailing lists, 
monthly informal electronic reports, quarterly reports, and regular meetings. 

Electronic mailing lists were maintained for the program participants (ttpp-pi), 
distribution of news, results, and monthly reports (ttpp-news), and the individual discipline 
groups (ttpp-es, ttpp-ls, ttpp-astron, and ttpp-micro). In each case, parallel lists were 
maintained for users on the Internet and NAS Amail. These mailing lists became quite 
extensive over the life of the program, with ttpp-news numbering over 400. Hence, a 
database of all participating and interested parties was maintained. 

Monthly informal reports were prepared and distributed electronically. These reports 
were for the purpose of providing timely informal exchange of information between the 
various testbed participants and other interested parties, particularly NASA personnel. 
Quarterly reports were prepared as the formal documentation of the ongoing program. While 
the intent was for both the monthly and quarterly reports to be brief status reports, the 
compilation of the reports from the large number of participating organizations (15) resulted 
in fairly lengthy reports, typically averaging approximately 60 pages for the quarterly reports. 
Nevertheless, feedback from the recipients of the reports, particularly those who were not 
participating directly in the program, was quite positive, expressing appreciation of the 
resulting ability for them to track progress. 

Finally, a number of meetings took place over the life of the program. In addition to 
informal coordination and review meetings with the various participants, two major meetings 
were held to exchange information and coordinate the overall program. The first meeting, held 
in October of 1987, focussed on initial coordination and refinement of program plans. The 
second meeting, held in March of 1988, was for the purpose of exchanging interim results and 
status. Each of these meetings was attended by roughly 100 people including both program 
participants and interested NASA personnel. A final meeting, held in November 1988, was 
held amongst a smaller group of program participants for the purpose of drafting this final 
report. 

Summary 

The TTPP represented an innovative approach to the involvement of university 
researchers in answering critical questions concerning the design of the future information 
system. Through the combination of ongoing scientific research emulating future operational 
science and advanced computer and communication technologies, much needed experience 
was garnered. By conducting the program as a multidisciplinary activity, considerable 
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profitable exchange of information between scientists in different disciplines occurred. Thus, 
in the opinions of the authors, the participants, and the other involved parties, the TTPP has 
proven to be a worthwhile investment by NASA. 
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Section 3 

Discipline Summaries 

In this section, the results and lessons learned from the various experiments are 
summarized with respect to their application to the scientific disciplines represented in the 
program. For each discipline, the participating parties discussed the results in a large 
number of technical and procedural areas. In Section 4, the results and lessons are 
integrated across the disciplines. 

3.1 Astronomy and Astrophysics Summary 

Many lessons have been learned in the astronomy and astrophysics discipline as a 
result of the TTPP and these lessons have helped in identifying requirements for Telescience 
in the Space Station era. Contributions to this discipline came from Cornell University, 
Massachusetts Institute of Technology, Smithsonian Astrophysics Observatory and the 
Universities of Arizona (College of Engineering and Steward Observatory), Califomia- 
Berkeley, Colorado and Maryland. 

The astronomy and astrophysics discipline differs markedly from the life sciences and 
material sciences areas. Specifically, astronomers are not able to alter their subject material 
in order to determine how it performs. When one has a new model of a supernova, one can 
not arrange to have a supernova against which to test one’s theory. Astronomers can only 
observe and this limits their interactions to instrument operations, data gathering techniques 
and realtime and quick look data analysis to support the observing program. The result is to 
establish a database to support ones research and that of the community. Thus in what 
follows, there must be a greater emphasis on remote observing and teleanalysis with the 
need for live video and voice communication between the scientist and the remote location 
limited to instrument and observing needs (eg. trouble shooting, or possible quick response). 

There are some aspects where results were anticipated, such as network performance, 
and other areas where there were unexpected results, such as the impact of using network 
capabilities for the administrative logistics of running a project. The aspects of telescience 
will be described in detail as they relate to the following topics: 

1. Teleoperation Of Instruments And Experiments 

2. Teleanalysis 

3. Use Of Networks To Enhance Programmatics 

4. Standards And Commonality 

5. Network Requirements 
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3.1.1. Teleoperation of Instruments and Experiments 

Nearly all of the astronomy TTPP had some component of instrument or experiment 
remote teleoperations associated with it. The extent of teleoperations varies from providing 
remote command and control to fully autonomous remote operation. All of the above aspects 
are what one can anticipate for teleoperations in the Space Station era; that is, remote 
operation of an instrument or facility with realtime or near realtime command and control to 
fully autonomous operations. The latter situation is what scientists have in many cases had 
to live with in the past, the former and a synthesis of automated and remotely controlled 
operations is what is hoped can be achieved for interactive experiment operations in the 
Space Station era. Fully autonomous operation does not come without a price tag. That is, in 
order to automatically point an instrument to its target accurately enough to perform a fully 
automated observation, a higher instrument precision is required than if it is foreseen that 
manual fine adjustments can be made during the observation after the coarse positioning 
(slewing) of the instrument has been completed. Also, manual intervention provides for an 
enhanced flexibility to modify the details of the observations to be performed. Some of the 
topics that have been studied in the TTPP with regard to teleoperations are: 

• Scientific productivity. 

• Astronomy education. 

• Instruments as network nodes 

• Common workstation for operations 

• Interconnection of multiple facilities 

• Robust design and safety “ 

• Data compression 
Scientific Productivity 

Most of the astronomy testbeds identified “enhanced productivity” as one of the end 
products of incorporating telescience methods and connectivity into the observation 
environment. SAO, MIT, University of Colorado and University of Arizona astronomy 
testbeds found that, through networking, not only was remote instrument control possible, 
but this connectivity provided access to near-realtime-data. Analysis of these data might 
result in needed changes in observation parameters and sometimes changes in the 
controlling program, as with the SAO Mt. Hopkins experiment. These changes were 
implemented remotely. Having immediate access to the observed data can result in 
enhanced science productivity, since the scientist can analyze the data immediately rather 
than having to wait until later when the data may be stale or the scientist gets distracted by 
other concerns. Teleoperation allows the astronomer to operate the telescope from his or her 
laboratory (or office) where all materials are available, and where every moment of waiting 
time may be utilized. Traveling times are reduced and, in some cases, the duration and 
quality of an observation can be enhanced. 
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Astronomy Education 

The University of Colorado team (LASP) studied this issue in a testbed in which a 
telescope located on campus could be operated from a remote location, such as a class room. 
This allowed the introduction of practical observations at a much earlier stage in the 
curriculum of ongoing astronomers than was previously feasible. This clearly enhanced both 
the motivation and the productivity of the students in pursuing their education. 

The MTT group has an ongoing integrated teaching and research program started 
concurrently with and based on its telescience program. By using the networking and 
computers (approximately 600) of which a major share (supplied by Project Athena) is solely 
for student use, the students have been placed in a combined research and teaching 
environment. They have full access (e.g. from living groups or dorms and campus clusters) 
to the data analysis programs. This is possible due to both remote login capability as well 
as the across the board use of UNIX, “C”, and “X” in most of the machines on campus and 
all of the machines in the Project Athena. Greatly broadening the base of participation in 
Space research is an important outcome of this type of operation. 

Instruments As Network Nodes 

Several recent instruments have been designed with the point of view that the 
instrument is a node on a network. The networks involved range from Local Area Networks 
(LANs) such as Ethernet to wide area networks such as the Internet. In the case of the 
EUVE project, the prototype instrument interfaces to one of the workstations in the LAN at 
the Space Science Lab. The software used to operate the instrument may be run from any of 
the other workstations or from any site with adequate connectivity. As the hardware and 
software development proceed, the network interface is maintained. In the case of SAO an 
IR array is operated and the data collected by a workstation which is a node on the Internet. 
In this way, support people can upload new software and debug and test new applications 
from Cambridge and support observing done with the array on a mountain in Arizona. The 
unique MTT highspeed CCD occultation camera is also in the process of becoming a fully 
functional network node (it has had a limited capability since inception). Additionally, the 
observer can transfer the data over the network (while the observations are taking place) to 
the data analysis facility and evaluate the results in near realtime to assist in the 
observation plan while still at the telescope. The important point is that network 
connectivity is part of the instrument design from the start. 

Common Workstation for Operations 

If the instrument interfaces could be standardized, the same workstation could be used 
to connect to any of a series of different instruments to which the scientist needs access. 

This means a common software environment, user interfaces, and hardware interfaces, not 
necessarily common hardware. Such commonality also increases the scientific productivity 
since less time is spent on studying operator manuals of unfamiliar instruments. 
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Interconnection of Multiple Facilities 

Researchers collaborating on a scientific research effort are no longer necessarily 
located at the same physical site. It is extremely beneficial if several users can have access 
to the different instruments simultaneously and perform a coordinated observation. It may be 
desirable that, while one observer operates the instrument, another observer can receive a 
slave image of the observer’s screen (both status and scientific data). From the experience 
at SAO, it can be extremely useful to allow an expert, knowledgeable with the instrument, to 
login remotely from a home institution while an observation is ongoing to help troubleshoot a 
malfunctioning instrument. Otherwise, by the time the expert arrives on-site, the night and 
the scheduled observation time may both be long gone, and the observer may not get another 
chance to observe for several months to come, or the opportunity may be lost. 

Robust Design and Safety 

This issue was studied by several of the research teams involved in the TTPP effort. If 
an instrument is operated under remote control, the experimental setup must be equipped 
with additional safeguards which compensate for the lack of physical presence. Even when 
instruments are designed for remote operations from the start, careful attention must be paid 
to the operational safety issues. The facility must have sufficient reactive control and 
interlocks to ensure the safety of the facility and on-site personnel. Safeguards are needed 
to monitor an ongoing experiment, and initiate automatic saving and recovery procedures if 
something goes wrong. Motion commands, for example, should be fully contained and to 
execute completely or not at all in case of a communications failure. A separate “start” and 
“stop” command would be vulnerable to communications failure before the “stop” command 
is received correctly. A preferred mode is to use fine adjustments to a pre-programmed and 
planned system. 

The trade-offs involved in automation must be carefully considered. Complete 
automation may be too expensive compared to having some on-site personnel. Satellite 
experiments don’t have this option, but Space Station experiments might. Fortunately, most 
operations in' astronomy are not time critical and it is therefore possible to build instruments 
that satisfy the above stated demands. There must be sufficient command and telemetry at 
the remote site to give the remote user sufficient information of the current status so that 
adjustments can be made to maximize the science. The data links must be sufficiently 
reliable to allow for critical modes of operation. Data rates of 9600 baud with delays of up to 
5 seconds will handle normal operations of a telescope without any video. This kind of 
throughput and latency is typically available on the present networks, but not assured. For 
critical or highly interactive operations, occasional use of a priority channel is needed with 
less than I second round trip delays. To handle longer delays requires use of special 
techniques which rapidly become more complicated and less effective. 

Data Compression 

The most serious problems with teleoperation of equipment are the demands on video 
feedback, since video data very quickly consume the entire bandwidth available for data 
communication. Fortunately, astronomers usually do not require high bandwidth video 
images of their telescope and its environment. Sometimes it may be useful to receive limited 
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video of the instrument to check for proper shutter, aperture, and filter motions, to verify that 
everything is okay, or to check why something went wrong. However, the astronomer can 
easily wait for 30 seconds to receive the bitmap. Video monitoring of the observation itself 
is another matter. Single CCD images typically require from fractions of a second to many 
minutes for integration. Solar instruments where dynamic processes on the sun are being 
studied along with planetary occultation studies (MIT) require shorter integration times. 

The University of Arizona Engineering Department studied methods of data reduction for 
starfields. They developed a technique which allows them to reduce the data stream from 8 
bits per pixel to 0.015 bits per pixel for the purpose of automated instrument positioning and 
tracking control, and for quicklook. However, other cases require much more information in 
order to determine detector noise performance, field variability (e.g. a solar glint dependent 
on spacecraft orientation) or overall instrument performance. Data reduction for the purpose 
of archival storage of scientific information is another issue and the gains achievable in 
compression may be offset by the computation needed to first compress the data and later to 
decompress the information. 

3.1.2. Teleanalysis 

Telescience principles are applicable to data analysis in two areas; teleanalysis by the 
community at large of established databases, and teleanalysis within a project group of a 
new or developing database. The various science disciplines within NASA have already 
addressed the community requirements and defined their architectures with the Planetary 
Data System (PDS), the Earth Science and Applications Data System (ESADS), and the 
Astrophysics Data Systems (ADS). Some of the general requirements that have come out 
of these architectures are: 

1. Very capable networks with connectivity to all scientists. 

2. The widespread use of workstations such as Suns and micro VAXes with 
imaging and graphics capabilities. 

3. The need for a browse system to help find information in a number of distributed 
databases. 

4. Recovery of the data over the network or via shipment on media. 

5. Data standards to permit universal exchange of data. 

6. Remote access to unique resources such as image processors or 
supercomputers for performing the analysis. 

7. High bandwidth requirements for remote image processing. 

8. Uniform ways of displaying and scientifically manipulating images. 

9. Standard software tools for analysis that can either be used remotely or ported 
to the investigators’ home institutions. 

10. Need for software documentation and "yellow pages". 
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The investigators in the TTPP have addressed various of these issues from their own 
project view point. Their experiences are relevant to the community at large and for 
telescience in the Space Station era. The group of investigators within the TTPP (University 
of Arizona Astronomy, Cornell University, NASA/ Ames and SAO) who also represent each 
of the SIRTF instrument teams and project management, represent a good testbed within 
TTPP for these specific discipline wide architecture issues. One of the University of Arizona 
astronomy testbed experiments was to report on the network performance for remote access 
of a large astronomical database at the Infrared Analysis and Processing Center (IP AC). 
However, this experiment was not very successful, mainly due to poor network connectivity. 
The SIRTF team is beginning to look at the level of commonality required for hardware and 
software, so that once the SIRTF development has been completed by the separate teams, 
the hardware and software delivered to NASA for the science operations center (SOC) is 
coherent and functional. Therefore, items 2, 5, 9 and 10 in the above list have to have been 
worked through. In addition, for the rest of the astrophysics community to be able to have 
access to the data, items 1, 3, 4, and 5 need to be addressed. Within the astronomical 
community, items 5 and 9 have already been defined, that is, ERAF and AIPS have been 
developed and are in wide spread use as an environment for data analysis, and FITS has 
been adopted as the format for data transfer. 

With the establishment of the IUE, IRAS and Einstein databases on-line at the 
institutions of origin, the issues of capable networks to permit teleanalysis becomes very 
relevant. Various of the TTPP investigators are trying out teleanalysis to learn what is 
practical and where the pitfalls might be. This approach to doing scientific research is not 
unlike what is anticipated in the Space Station era when access to many widely distributed 
databases will be necessary for performing an investigation. 

The MIT groups connection to Project Athena has enabled them to deal with 
interactions between a private environment and a public multimachine net over a high 
bandwidth link. The issues of security and ease of use were two of the areas investigated. 

3.1.3. Use of Networks to Enhance Programmatics 

Although it was not part of our investigation plan, we have found that the network 
connections between the various participants in the TTPP has greatly enhanced our overall 
productivity for the program. This is not something that can be easily quantified. However, 
from our daily experiences with using the network we know that it provides a significant 
improvement in the day-to-day activities performed separate from activities such as 
teleoperations or teleanalysis. Specifically, the program office at RIACS from the very 
beginning has used the networks almost exclusively for communicating with the 
investigators. This has worked very well. The investigators in like manner have also been 
communicating with each other as well as with RIACS via networks. We have found this to 
be a very effective means of running a program and many of us have adopted the technique 
for our own general form of communications and have in many cases made it our first and 
primary choice. Electronic mail (e-mail) is probably the most familiar usage of networks to 
the casual user; however, the networks have been used for many other purposes as part of 
the TTPP program. We have found telemanagement to serve a vital function in the following 
areas: 
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• On-line documentation 

• Submission of reports 

• Proposal preparation and evaluation 

• Electronic mail (correspondence/historical record) 

• Electronic mail (information distribution) 

On-line Documentation 

Since nearly everyone is now using word processing in the office, it should no longer be 
necessary to distribute hard copies of every document to everybody. Rather, once the 
document has been approved, it should become available on-line to all users. Being on-line 
has many advantages, including everyone having the same and most up-to-date version to 
work with. Specifications, requirements, etc. tend to be poorly indexed if at all, so that 
standard electronic (text- or content- based) search routines must be used to locate all 
references to a particular item. This can also assure more accurate revisions when changes 
are made. 

Submission of Reports 

All reports of TTPP have been electronically generated and maintained. This has 
drastically reduced the reporting time between the Pi’s within the individual research teams 
and with the TTPP project office. Additionally, reports could be edited readily from the 
electronically stored information. 

An excellent example of how this was used was in preparation of the area quarterly 
reports. In this case, each PI wrote his or her own quarterly. In addition to submitting them 
to the project office, a copy was sent to the area coordinator who could then use the 
information contained in the individual PI reports to create an area summary report. As part 
of the summary, the area coordinator performed a survey of the Pis asking for information on 
hardware, operating systems, software, network usage, etc. This poll was conducted over 
the network, results received as e-mail which could then be easily and rapidly be collated to 
produce the area summary report each quarter. Depending on verbal responses or delivery of 
“US snail” would have made the task much more difficult and time consuming. 

Proposal Preparation and Evaluation 

For the TTPP, the original proposals were submitted and reviewed electronically. 
Proposals for observing with spaceflight instruments in the Space Station era will be 
considerably more complex, particularly when timeline planning, instrument capabilities and 
resource allocations are included. Many of the constraints are quite technical, such as, 
thermal, power, guide stars, momentum management, orbit ascending node, etc. Experience 
has shown that these constraints interact in complex ways which make it very difficult to 
determine the feasibility and possible alternatives to proposed observations prior to formal 
submission of an observing plan. Remote use of artificial intelligence could be of great 
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benefit for formulating proposals. Once the users have worked out the observation plan to 
their satisfaction, the planned activities would then be generated by an expert system in a 
standardized format for submission as a formal proposal. 

Electronic Mail (Correspondence/Historical Record) 

E-mail is one of the most useful aspects for making timely contact with other people. 
E-mail provides the details and self-documentation that has been lost with phone 
conversations. (Prior to the use of phones, history and documentation was preserved via 
letter mail records.) Also, unlike a telephone where either a person gets interrupted by the 
phone or may not be present to answer the phone, e-mail provides a recorded message 
which can either be acted upon immediately or deferred and is delivered whether or not the 
person is present. 

Another major aspect of e-mail is the speed which provides nearly instant delivery and 
thereby speeds up the completion of activities. Many times in dealing with an issue several 
messages can be transmitted back and forth with an hour, avoiding playing “telephone tag”, 
providing written explicit information and a complete record of the “discussion”. 
Additionally, with e-mail one has electronic copies of the information which can be further 
distributed, edited or combined with other data, rather than having to re-type the 
information. E-mail does not present a heavy network load and the network throughputs are 
satisfactory in both bandwidth and latency for e-mail. 

Electronic Mail (Information Distribution): 

E-mail has been particularly helpful in providing for information distribution. There are 
several distinctly different categories of information being distributed for a number of differing 
reasons: 

• Meeting agendas, notices, announcements and other forms of general and time 
critical data which are broadcast with no response expected. 

• Documents that are being distributed for review and comment. These could be 
for document preparation purposes or could be for formal review such as that of 
proposals. Responses are generally expected or required. 

• General distribution of completed documents. This is an area where caution is 
needed, that is, both from the standpoint of load on the network and filling of 
disk space at the recipients end. In general, we would recommend only 
distributing of final documents upon the specific request of the end users rather 
than the broadcasting approach. 

There is a need for a central repository of e-mail addresses (‘white pages’) for 
astronomy (or planetary or other disciplines. Currently, sometimes the only way to get an e- 
mail address of someone is to call them on the phone. Even then, frequently it takes several 
tries to figure out the correct syntax of the address. It would greatly improve the capabilities 
of the e-mail system if there was a directory service, either through a printed phone book or 
through an on-line directory. 
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In the astronomical community, work is in progress to provide this service. STScI is 
coordinating the development of the “ASTIS” login, which will provide a remote login 
directory service. The American Astronomical Society is planning on providing a printed 
directory by simply adding e-mail addresses to their current directory. 

3.1.4. Standards and Commonality 

An area which can make or break the success of a project is standards and 
commonality. What increased American productivity was the use of standard parts in an 
assembly line. The same is true with the tools of science through use of a standard 
hardware and software environment. This is particularly true for the cases where 
teleoperations and teleanalysis are incorporated and many users from various institutions 
are trying to make use of the same equipment or data. In the TTPP we did not make any 
attempt to select, decide upon or even study standards. However, from surveying the 
various participants it was found that there may already exist a level of de facto 
standardization. In particular, nearly everyone is using either a microVAX or Sun 
workstation. Nearly all institutions are connected via Internet and are using either Unix or 
VMS as their operating system. 

For the future it would be beneficial to adhere to vendor independent and commonly 
used software such as: 

1 . X window manager 

2. NFS network file system 

3. an operating system such as Unix 

4. TCP/IP protocol 

5. an image display interface standard 

6. data formats such as FITS 

7. graphics packages such as GKS 

In addition there are a whole host of utilities that are used such as text formatters, 
editors, mailers, compilers and database managers. Astronomers have gone a step further 
and developed analysis environments such as AIPS and IRAF which have become widely 
used within their community. 

Standards would also prove helpful for word processing. One of the benefits of 
networks is the ability for geographically diverse groups to collaborate on science projects. 

An immediate consequence of such collaborations is the need for geographically separated 
authors to collaborate in the writing of research papers. Within the astronomy and 
astrophysics community (and this is clearly not unique), this has been hampered by a 
“Tower of Babel.” Different word processing software (TeX, LaTeX, nroff, troff, runoff, Word 
Perfect, etc.) are used. Consequently, when papers are passed between participants, either 
the users must convert everything to unformatted text, read unfriendly text-formatting 
commands interspersed with text, or rely partially on US mail to exchange printed copies 
using e-mail for comments. This situation would be greatly improved by a) standardizing on 
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one system (unlikely to occur), b) translators to map between different systems, or c) 
standardizing on the interface, e.g. by using PostScript for exchange of documents. Similar 
problems with similar potential solutions exist for exchange of graphics and other media. 

3.1.5. Network Requirements 

A very critical component of Telescience is the communications capability. For the 
Space Station era, this is not just the link between the Space Station and the ground or any 
other orbiting facility and the science operations centers such as from HST to the STScI, but 
equally important is the network connection between the scientists at their home institution 
and the science operations center. The emphasis of network requirements for teleoperation 
is different from that for teleanalysis. Specifically, as part of the TTPP, performance and 
requirements in the following areas have been studied: 

• Network latency for realtime closed loop command and control. 

• Network reliability for realtime closed loop command and control. 

• Network bandwidth for data transfer. 

The first and second points are very important for teleoperations and have been 
addressed in the teleoperations section. Long latencies may make it difficult or impossible 
control instrument functions which are changing and require realtime feedback for control, 
addition, one would want the network connection (and accessibility) sufficiently reliable to 
able to accomplish a task without great delays or without having to attempt it many times 
due to loss of connectivity before completion. Clearly, any teleoperations activity must be 
designed so that with any large latency or loss of connection, the instrument or personnel 
will remain safe and the experiment objectives not ruined. It has been shown by the 
University of Colorado team that latencies of more than 30 sec. will usually result in an 
attempt of the remote operator to resubmit the request. It is therefore important to make the 
interface insensitive to repeated requests in addition to limiting latencies to a decent value. 
Most people consider latencies of more than 5 sec unacceptable when operating an 
instrument. As a result of the TTPP, the following points can be stated with regard to the 
use of networks for astronomy and astrophysics: 

• For highly iterative command and control, occasional use of a “priority channel” 
is needed with an overall round trip time delay less than one second. While 
somewhat longer delays can be tolerated, this requires use of special techniques 
which rapidly become more complicated and less efficient. 

• The systems need to be “hacker” proof. 

• There is little requirement for broadband video or voice. 

• Cross network access needs to be made easier. 

• The user should have some control over routing to direct connections over 
known high bandwidth connections. 

• More rapid installation of new nodes and lines is needed. 

• A central information office is needed to help novices get started or to handle 
issues. 
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Some of the reliability and throughput problems appear to be due to the inability of 
some sites to take advantage of nearby high-speed data connections. Many of these 
channels have access restrictions (understandably so), but there are TTPP participants who 
are entided to use these links but are connected to the Internet through a University network 
that is not so entitled. This effectively cuts off the TTPP participant from access to the high- 
speed link. Improved routing software and hardware may be part of the answer, but where 
this proves inadequate, there should be support for installing connections from qualified 
organizations to the high speed lines. Specific projects may still require dedicated point-to- 
point links. 

The question of the required performance is very dependent on the usage. The 
following table is a qualitative summary of the network performance experienced by the 
astronomy TTPP participants. 


Table 1: NATIONAL NETWORK PERFORMANCE: 



E-mail 

File transfer 

Remote login 

Instrument control 

Internet 

Good: 

Inadequate: 
rate too low 
for large files 

Marginal: 
drop connect 

Inadequate: 
unreliable 
latency too long 

SPAN 

(DECnet 

only) 

Good: 

Marginal: 
rate too low 
for large files 

Good: 

Marginal: 
unreliable 
latency too long 

Bitnet 

Good: 

Inadequate: 
rate too low 
for large files 

Not possible 

Not possible 


Note: NSN not installed widely enough to have any performance results. Typical 
transfer rates are about 1 kbytes on national networks. Regional or campus 
networks are not included, since in general they have T1 bandwidth and are 
good or adequate for nearly all purposes. 


The bottom line from the experience of the astronomy Pis is that for e-mail the 
networks are adequate, but for most other functions they are woefully inadequate. 
Specifically, the measured transfer rate for files is typically on the order of a kilobyte per 
second. Commonly available modems have about the same performance. Unfortunately, it 
will probably always be true that the users will fill the available network capacity, whatever 
it is. The situation is somewhat better for performing remote logins. On SPAN it seems to 
be fairly good. Not only is it possible to have good connectivity in the U.S., but also to 
computers that are on SPAN in Europe. However, on the other national networks the 
reliability is poor, both in terms of getting access and in having a sufficiently long connect 
time without getting dropped, that is for a fraction of an hour to several hours. Hopefully, for 
TTPP users this will improve with NSN providing TCP/IP for non-DEC machines. 
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Ail in all the biggest difficulty is that the network bandwidth is too low and unreliable to 
perform most of the science functions envisioned. Recall that one of the major objectives of 
the overall TTPP was to determine the network communications requirements for performing 
Telescience in the Space Station era. A big plus for all of the Pis is that they have all 
become used to using the networks for e-mail and exchanging of information with each over 
the network. This has definitely improved the individual’s productivity. Furthermore, higher 
performance networks (both bandwidth and latency) with wider connectivity can be 
anticipated in light of new national initiatives in this area. 

3.2 Earth Sciences Summary 

Overall, the Earth Sciences discipline group found that an awareness of telescience, 
broadly defined, plus access to the required tools and infrastructure, can positively effect the 
conduct of earth science. The following details some of the key issues and opportunities 
which came from our work in the past year. 

3.2.1. Teleanalysis 

Security issues were raised during the Earth Sciences TTPP activities. Secure access 
methods had to be implemented in the database systems at several of the universities; in 
some cases these were installed after users corrupted the systems. Similarly, priority- 
based mechanisms were required to avoid conflicts between realtime system operations and 
retrospective analysis users (based on the University of Wisconsin’s experience with 
McIDAS). 

Many of the activities in our area revolved around database issues. We see a need to 
investigate common user interface standards, as well as standards for database description 
and format. We feel a strong need for a high level catalog and directory for earth science 
datasets, to help guide us through our search for relevant information. We believe it is 
important that standards in the area be enabling, rather than constraining. Standards for data 
description are more important than detailed standards for data formats themselves. A 
centralized facility for guidance in creating and maintaining earth science database 
descriptions/catalogs and, when sensible, the actual datasets themselves, perhaps through 
NSSDC, would be valuable to several of the team members. We recognize the value of such 
efforts as the Catalog Interoperability initiative, and strongly encourage them. 

In the operations environment, there has been some de facto standardization on the 
OASIS system. Particularly for realtime and quick-look type requirements, we suggest that 
future programs examine options to satisfy these requirements for teleanalysis. A library of 
tools for such realtime functions (including data stream decomposition, rapid graphic display 
of standard kinds of numeric data, bit packing and decompression, a small set of signal 
processing tools, etc.) could be very valuable. 


February 1989 


RIACS TR 89.8 


E-32 



TTPP Final Report V. H/Program Results 


Sect. 3/Discipline Summaries 


A function, which we never addressed in our experiments, involves the remote use of 
colleagues’ analytic systems. While we were interested in making use of remote software 
and computer systems, a number of specific issues made it impossible during the TTPP 
program. In order to exercise such capabilities as a program-wide systematic function, it 
would be necessary to provide: 

• high-level directory of capabilities 

• documentation 

• accounts 

• guidance 

• multiple terminals watching the same process (in the general idea of remote 
coaching and multimedia mail) 

• network with sufficient throughput to provide graphics/image displays within an 
acceptable time. 

These may make it possible to collaborate with others more effectively, while 
minimizing the travel costs and time, and without having to move large software 
environments between institutions. 

We applaud the effort towards a standard software environment for the telescience 
community. We hope that this effort can be expanded and be able to support the other 
popular workstation platforms in the community, in particular, Macintosh, IBM, and 
VAXstation. The issues here involve addressing a portable workstation for work in the field, 
in addition to including a larger fraction of the earth science community with their existing 
hardware platforms. 

3.2.2. Teledesign 

In software design for teleoperations, it was important to duplicate the development 
environments at each of the collaborating sites, particularly during debugging phases. 
Debugging across the network was extremely difficult without this kind of duplication. The 
shared 56kb network connections were found to be adequate to the debug task. Moving 
software and software environments between sites was found to be much more difficult than 
anticipated. 

Project scheduling overall was found to be much more difficult than anticipated. The field 
campaigns, for example, required coordination and logistic planning between several 
university groups, NASA laboratories, other public agencies, and the private sector. These 
were relatively complex, and a major problem during the past year which affected the 
quantity and quality of the science. 

The design of experiments in which geographically distributed scientists were to 
participate was limited to e-mail communications. While this is a significant improvement 
over conventional mail and telephone tag, we foresee the need for significant improvements 
in this area as we begin to plan more sophisticated collaborative research. 
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3.2.3. Network Infrastructure 

Several different levels of network services were required across the Earth Sciences 
activities. Access to data directories and inventories were sometimes provided by existing 
mechanisms (i.e., SPAN, the Internet, and dial-up modems), depending on time of day and 
consideration of number of hops. Interactive remote graphic sessions were often 
unsuccessful over the Internet; frequendy sessions were dropped, even when file transfers 
between the same points at the same time were generally reliable. Dial-up modems, 
although often not sufficiently fast, were usually reliable in these instances. In some 
circumstances (such as quick-look data views), a modest amount of noise on the line is 
acceptable, particularly when the error rates are known. 

A number of experiments involved interactive remote display of bit- mapped graphic 
images (either interactive or based on file transfer followed by local display). It was the 
group’s experience that 9600 bps throughput was not sufficient, in some cases by factors of 2 
to 20; we note that the recent 30 second round-trip delay for cursor movement over the 
Internet between California and Purdue is of course unacceptable. The goal overall of 10 to 
60 seconds for reasonable workstation displays is required for such things as browse of 
remote image repositories, including compression/decompression as required. For other 
purposes, rates as low as 1200 bps are acceptable even when the display time is still the 
same as above, since the data density is lower for vector and statistical graphics. One 
possible solution might involve providing different levels of service (in terms of throughput 
and latency) for different kinds of needs; this is different from the capabilities we now use 
under SPAN and the Internet. 

We recognize that new capabilities do indeed spawn new requirements; we anticipate 
that improved network throughput and reliability will move us to use these services more 
extensively. 

An important lesson involved the institutional overhead required to establish network 
connectivity. The temporal planning cycle at many institutions is substantially longer than 
the TTPP program as a whole, thus limiting our abilities during the program. 

Several cases of using one university to interface others were found during the 
program. For example, one of the DEC systems at UCSB runs both DECNET and the 
Internet protocols. Purdue did not have direct connectivity with Colorado: Purdue remotely 
logged onto UCSB via ‘telnet’, and then logged into Colorado via VMS ‘set host’. This was 
useful to bridge between systems until such time when universal connectivity is possible 
between all the team members. 

A mechanism for verifying the result of a file transfer, analogous to a return receipt 
mechanism in an e-mail package, was identified as a useful service by several in the group. 
There were several instances where a file transfer task did not run to completion, and the 
investigators were not alerted to any problem. Further, when a transfer is interrupted, 
typically the entire transfer must be repeated; the Internet does not seem to support a 
mechanism to save the portion of the file that has been sent, and then continue the transfer 
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from that point. This is particularly important when attempting to transfer relatively large 
datafiles. We note that some existing file transfer protocols (e.g. Z-modem) already includes 
this capability. 

Dial-up lines, while generally reliable, displayed some inconsistencies in our 
experiments. At times, it was even impossible to reliably detect the carrier. These examples 
make us uncomfortable relying on dial-up lines for mission-critical applications. It is 
probably still fair to say that dial-up access is suitable for many other kinds of uses. We are 
concerned that there are still several incompatible protocols for 9600 bps dial-up modems 
that are in common use. We also note that we have had little success with one of the 9600 
bps modems over a satellite dial-up link. 

3.2.4. Operations 

Within the operations scenarios worked by the group, person-to-person 
communications mechanisms were very important. The UNIX ‘talk’ or VMS ‘phone’ 
mechanisms were essential in demonstrations where direct telephone or voice 
communications were not possible. 

Scheduling access to satellite observations was difficult. An understanding of the time 
requiredto scale up for a set of operations is one of the clear lessons learned from the TTPP. 
The reactivation time for SME was up to a month due to the need to schedule TDRSS 
support four weeks in advance of our operations, where the planning horizon for the rest of 
the campaign observations was approximately 10 days. 

The time it takes to implement a testbed in the operations area is strongly dependent 
on the background of the investigators. Scientists without either ongoing hardware 
development or long experience in the operations area have a much more difficult time. 
Establishing a remote data acquisition site was very painful. Better mechanisms for near- 
realtime data dissemination of science data will benefit a number of the science programs in 
this area. 

3.3 Life Sciences Summary 

Life sciences requirements are summarized under two broad areas. Section 3.3.1 
presents an overview of how life sciences differ from other disciplines. This section points 
out some of the special needs and characteristics of life science experiments, and relates 
them to work in Telescience at three NASA Centers, and at MIT, University of Arizona, 
University of Colorado and Stanford through the Telescience Testbed Pilot Program (TTPP). 
Section 3.3.2 summarizes the life sciences testbed experience and derives requirements and 
advocacy for 23 functional areas supporting telescience. 

3.3.1. How Life Sciences Differs From Other Disciplines 

The nature of most space life science experiments that can be envisioned for the next 
two decades must, of necessity, draw upon our experience from such experiments during 
past missions. The missions most relevant to the Space Station are the Skylab and 
Spacelab experiences. In both cases, significant advances in biomedical science resulted 
from investigations which made intensive use of the crew as both subjects and 
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experimenters, increasingly involved the ground investigators in the experiment, and 
permitted some experiment modification on the basis of the observations. The process has 
been stifled, to a certain extent, by the limitations in communication and control from the 
ground, the limited crew time and resources for flexible experiment replanning, and the time 
delays in data availability and initial analysis. In the forthcoming Space Station era, many of 
these technological bottlenecks can be removed or reduced, providing they are identified 
early and corrected on the basis of scientific return and efficiency. 

Principal Investigator (PI) Interaction 

During the course of a typical life science space experiment the PI can be heavily 
involved in several aspects of the conduct and management of the study. These activities 
include monitoring, observation, manipulation and management. 

Monitoring 

While an experiment is running, whether or not an astronaut is in active control, the PI 
is involved in monitoring the status of the instruments, resources and the condition of the 
specimen. An experiment may have to be altered or terminated if any of the monitored 
variables indicate a deteriorating situation. In order to use all of his or her expertise in 
determining these judgements, the PI must have timely and sufficient data. In many cases, 
the nature of the data may not have been foreseen, and might involve a new probe or an 
additional video scene to be set up by the astronaut. In the Space Station scenario, with 90- 
180 day tours of duty and many experiments, it is not reasonable to expect the astronauts to 
be trained to the same level of expertise on each experiment as might have been the case for 
a shorter mission. On board “coaching” becomes necessary. To enable the PI to monitor an 
experiment, the inclusion of commands for new measurements may be necessary, as well as 
the inclusion of an Expert System to provide the astronaut with consulting advice and 
troubleshooting diagnostics. 

Observation 

During the conduct of an experiment, the life sciences PI is actively involved in 
experiment observation - to adapt to scientifically interesting data and leads, as opposed to 
monitoring the status of the experiment. Unlike many physical science experiments, where 
the nature of the phenomenon is well known and the data are largely a numerical value, the 
life scientist is usually exploring the very nature of the phenomenon - and often just fishing in 
a very promising area. The PI will need both instrumentation and especially a wide choice of 
imagery, including video views from various angles of a plant or animal specimen, the human 
subject, or a microscope slide. Only with sufficient and flexible downlink and uplink can the 
proper data be called for and evaluated to put the PI “in the picture” for the conduct of the 
experiment. 

Specimen Manipulation 

Not only is observation required but manipulation of the experiment is also essential if 
the PI is to participate actively in the data gathering phase. It may not be sufficient to tell 
the astronaut what view is required, or how to shift an instrument or how to adjust a 
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pressure setting. Rather, the experimenter may need to have a “hands on” involvement 
that has not thus far been available for space investigations. If the apparatus is to include a 
controllable robot, or a “third hand,” it may be under the joint control of the astronaut and of 
the PI. 

Management 

During the conduct of an experiment, the PI is frequently involved in the tracking of 
critical resources, such as crew time remaining versus progress in the experiment. The 
astronaut typically has neither the time nor the “big picture” of the experiment’s scientific 
progress to suggest that certain steps be omitted, repeated or re-ordered. If the PI is to 
make these judgements, however, sufficient data regarding the progress of the experiment 
and the status of data, power and crew time resources must be made available promptly. 

Sharing of Specimens and Data 

The Space Station-era life sciences program involves the design of space-based 
laboratory facilities to meet the requirements of a diverse group of science disciplines. After 
the necessary equipment is designed, tested, installed on orbit and made operational, 
several experiments are likely to be carried out simultaneously. In many cases, particularly 
while on-orbit research capacity is still limited, these investigators will share a common pool 
of animal and plant specimens. These multiple lines of research must obviously be 
coordinated, and yet each investigator should have some ability to influence his or her own 
research. Finally, the data from space-based experiments must be made accessible to the 
appropriate members of the science community in a format, and with a small enough delay, to 
permit planning and implementation of follow-on research, based on results and findings, in 
an uninterrupted flow. 

Access to Databases 

It is essential in life sciences that principal investigators and space vehicle crew have 
access to both onboard and onground databases. The crew will want to look at onboard data 
as part of routine monitoring, and out of scientific curiosity linked with their roles as team 
participants in the research. Ground-based investigators will naturally turn to the data in 
active ground-based databases, as well as to more archival data as they undertake their 
planned analyses. The crew will also want to get information from the ground, however, and 
the scientists on Earth will often want to access data that is still stored in space. Principal 
investigators will often wish to examine very recently collected data while it is still stored on 
the spacecraft, e.g., to evaluate its “reasonableness” in general, or to check on specimen 
reactions to some experimental intervention. The crew may request, or the investigators 
may transmit on their own initiative, a variety of data (perhaps after some processing), such 
as, text, graphics, and video information for such purposes as facilitating scientific 
discussions between ground and orbit, demonstrating new or difficult procedures, or helping 
the crew troubleshoot and repair equipment. A number of these information transmission 
activities may involve expert systems technology to help select and use relevant portions of 
databases more quickly and effectively. 
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Networks for Experiment Science Team Simulation/Training 

Life science experiments are genetically crew time intensive, and frequently involve 
realtime air/ground interaction over voice and video channels with PI teams on the ground. 
Training via high fidelity simulations has historically played a critical role in achieving and 
maintaining team proficiency. The design of the overall Space Station Information System 
(SSIS) must include the capability for conducting high fidelity crew and PI training sessions 
in interactive mode, with the crew relocated in a mock-up on the ground or aboard the station 
in orbit, and the Pis located at their workstations at their home institutions or in nearby 
Discipline Operations Centers (DOCs). 

Experiment durations in Space Station will be measured in months rather than by days. 
Time may not be available for detailed experiment training sessions prior to launch, as they 
were in the Spacelab era. These factors indicate the need for an on-board, interactive mode 
of experiment training, preparation, and performance between the crew and the PI. 

3.3.2. Functional Areas Supporting Telescience 

The experience of participating Universities and NASA centers in the TTPP is 
summarized in 23 functional areas supporting telescience. This section describes life 
sciences requirements and advocacy in each of these areas. 

Planning and Scheduling 

To decrease scheduling conflicts during operations, commitments from communication 
links suppliers for high priority should be obtained or dedicated virtual circuits should be 
used. By implementing either of these suggestions, last minute conflicts should not interfere 
with experiment operations. 

For experiment resource allocation before and during experiment operations, scheduling 
software tools should be developed. Using this software, crew time, experiment hardware, 
and SS communication networks can be allocated dynamically as experiment operations are 
conducted. 

Remote Coaching 

Both the conduct of nominal operations and malfunction analyses and resolution were 
enhanced by the direct Pi/crew interaction during operations. This enhancement was most 
effective during unrestricted communications access and degraded as the restrictions on 
communications increased. It is impossible for the crew to have as much in-depth 
knowledge of a particular experiment as the Pis have. Therefore, “coaching” is very 
effective. The requirements for successful “coaching” include: 1) realtime downlink and 
occasional uplink, 2) unrestricted audio, and 3) a prior common knowledge base (training, 
common language, experience with common systems). 

One of the three life sciences scenarios which is being carried out within the Space 
Station mock-up at Ames involves remote coaching of the flight crewperson by an expert 
who was located remotely. Full frame color video and high fidelity audio are also provided to 
the flight crew within the glovebox enclosure as is a graphic illustration on a Macintosh of 
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the specimen to be dealt with. We found that as long as the integrity of all three two-way 
voice communication channels and an uplink channel are maintained, and all supplies are 
available, the flight crewperson can perform the required operations remotely. Coaching 
takes the form of coordinated verbal and visual cues from the expert as to color patterns on a 
leaf that have to be precisely cut and snap-frozen within the glovebox. Also, distributed 
workstations proved very helpful in providing the distributed collaborators cognizance while 
the crew performed complex experiment procedures. 

Monitoring and Maintenance 

Monitoring of experiment set-up is as important as surveillance of actual experiment 
execution. Realtime audio, video and data communications are required for the ground to 
effectively monitor and track experiment progress. This includes tracking resource use 
versus allocation, monitoring the status and results of the experiment and providing 
immediate help for maintenance of off-nominal conditions. With the capability for realtime 
video, the MTT experiment saved time when the “crew” could skip specific steps in the 
procedures as directed by the ground. Without telescience, they would have had to perform 
these steps as a matter of course. Similarly, realtime digital data allowed the PI to judge the 
quality of eye motion data and instruct the crew to check amplifier drifts, electrode placement 
or proper experiment set-up. 

Arizona’s testbed included a failure mode simulation. This demonstrated that with 
9600 b/s status telemetry, anomalous conditions can be detected and the remote operator 
alerted to take recovery actions or perform necessary maintenance. 

Colorado determined that several essential ingredients were necessary for a 
distributed environment: (1) The user/scientist needs enough status, configuration, and 
health information to understand the experiment. If this information is not available, the 
scientist will have to work locally at the experiment location, where the adequate information 
is available. That is, science is not dependent on location relative to the experiment, but is 
dependent on the amount of information available; (2) The user scientist requires feedback 
for each control direction. The allowable delay for this feedback is dependent on the 
operation; (3) The user needs to be informed of any activities that are automatically 
performed by the instrument or onboard subsystem. 

Data Compression (non-video) 

A number of data compression techniques were investigated. Results of on-going 
studies are not yet complete. A lossless methodology of data compression may be required 
for data storage and archival. Data transmitted for monitoring or “quick-look” analyses 
may be lossy or lossless. Lossless compression (no loss of information) must be used (if 
required by network bandwidth constraints) to maintain original data integrity; stored data 
and data for rigorous analysis must be complete or available in a lossless compressed form. 
Since full (no loss) information is not essential for monitoring or “quick-look” analysis, 
lossy compressed data may be acceptable. At present, life sciences do not have any 
requirements for data compression. 
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The technology experiment conducted by Arizona showed that the command/telemetry 
stream, using an appropriate intermediate language, does not require data compression due 
to the low information rates (never more than 9600 b/s, average a few hundred b/s), and will 
be more robust without such compression. 

Communication Parameters 

In the MIT/KSC experiment, the crew worked with open mikes in order to evaluate the 
impact of a dedicated, open mike voice link capability between the Space Station crew and 
the Pis. Both Pis commented that when compared to their own previous experience in 
Spacelab air/ground operations, the ability to listen continuously to open mike conversations 
between the crew made a major positive difference in their ability to keep track of the 
progress of the experiment (both with and without simultaneous video), and were surprised 
by the difference this one factor made. When Pis could speak to the crew without having to 
ask for permission, and without the 30 second “voice enabling delay’’ imposed in some of 
the sessions, the Pis were much more effective in assisting the crew in troubleshooting, or in 
following up on unexpected findings. 

Video/Audio/Data Latency and Relative Phasing: 

The MIT/KSC experiments imposed approximately 1-2 seconds delay between data 
and video/voice. Video and voice had approximately identical phasing, and less than one 
second delay. However, Pis frequently operated with video frame rates of 1/sec., and 
occasionally lower. Although technical limitations prevented the MIT/KSC testbed from fully 
exploring latency and phasing parameter space for video, audio, and data, certain 
requirements in this area can be stated with certainty: 

Time delays between data and audio/video of 1 second or less were clearly acceptable. 
Latencies of 1-3 seconds (due to satellite communications delays) are routinely 
accommodated in Spacelab operations. Time delays of 30 seconds between video/voice and 
audio (encountered by the same Pis in Spacelab operations) are unacceptable for remote 
coaching. Time delays between video and simultaneous audio (“the Bruce Lee movie 
effect”) - though subjectively noticeable - are probably acceptable up to about 3 seconds in 
most remote coaching situations. It should be kept in mind that voice monitoring greatly 
assists the PI in interpreting video information and vice versa, so acceptable criteria for 
phasing probably depends on video bit rate. In each of two quite different scientific 
experiments, Arizona was just able to transmit teleoperations traffic, (commands, status 
telemetry, and limited amounts of scientific data) at 9600 bits/second. This implies that each 
teleoperations connection should provide a minimum transmission speed of 19.2 Kb/s. A 
more reasonable requirement is probably 32 Kb/s or 64 Kb/s (ISDN B channel). 

A key parameter is round trip delay time (latency). Arizona’s studies showed that 
man-in-the-loop control of a robot was not possible with delays larger than 1 second. For 
near real time teleoperations using open loop (remote commands directing local autonomy) 
delay of less than 5 seconds is extremely desirable. 
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Colorado required a mix of audio, digital and video data for distributed laboratory 
science operations. Bandwidth limitations in any of these data types can be compensated for 
(at least temporarily) by varying the operations style. That is with limited bandwidth, the 
user directions must become more goal oriented (e.g., “go to brightest location”) rather than 
activity oriented (e.g., “turn left... go forward... stop”). 

The user must be able to compensate and respond to both scheduled and unscheduled 
data outages. This requires a certain level of automation to continue experiment operations, 
during these communication interrupts, the ability to respond automatically to unscheduled 
operations with safing procedures, and ideally the ability to reschedule these interrupted 
operations through onboard, automated services. 

Software 

In the Spacelab era, Pis have been asked to specify their POCC or life sciences SMA 
displays and data analysis systems many months prior to a mission. Typically, when Pis 
begin to participate in interactive mission simulations, and their understanding of their 
remote coaching and data monitoring function matures, PI display requirements change. The 
“optimal” display format typically is found to depend on which functional objective is being 
accomplished, and on the experience and workload of the PI. Existing software technologies 
from Spacelab do not make it easy for the PI to rapidly reconfigure PI display terminals. 

MTT/KSC developed a prototype PI Telescience workstation utilizing a networked DEC 
microVAX II running BSD Unix and a special version of X Windows developed at MIT which 
supported realtime video windows. Most of the programming was accomplished in C. 
Unix/X-Windows/C provided a powerful, flexible development environment for our 
experienced programmers. A number of generic data display window functions were defined 
which successfully supported both experiments. The Pis could quickly change the number, 
format, and placement of both graphics and video windows. However, due to the time 
constraints and the lack of a graphical block diagram compiler which would support virtual 
instrument and display prototyping and reconfiguration on the microVAX (comparable to 
Lab VIEW for the Macintosh), only a very few of the possibilities were explored. Also, the 
data processing requirements placed on the system would have been better satisfied by 
using more than a single workstation in a networked configuration. 

MIT believes that X-Windows represents a reasonable standard for the graphics 
substrate of a PI workstation, but that an additional set of graphics standards and virtual 
instrument/display toolkit would greatly facilitate display development and reconfiguration, 
both in the context of testbedding, and also before and during actual Space Station 
operations. PI workstation team training costs can be significant, therefore, telescience 
workstations should adopt user interface standards (e.g., Macintosh) for those functions 
which Pis use frequently (e.g., window management and text processing) which are very 
familiar to science team members in other contexts. 

The ability of Pis to simultaneously monitor experiment operations, evaluate incoming 
data, and maintain an adequate running logbook is critically dependent on the division of 
labor and experience of the Pis involved, and on the technology which supports them. 
Logkeeping is a critically important PI function. The MIT/KSC experiments demonstrated, 
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however, that logkeeping - even using a word processor - could be a very distracting task 
during high workload periods. Improved techniques should be developed to assist the PI in 
automated logkeeping. PI workstations should feature automatic timeline monitoring and 
display of “minutes ahead/behind.” Such systems could also trigger display of appropriate 
checklists for PI use in monitoring each experiment step, and context dependent 
troubleshooting checklists/diagnostic trees. Workstations should support “nominal data” 
displays for comparison with that obtained in session, and automatic reconfiguration of 
displays when a PI must “tune out” to work some side problem. 

Arizona utilized generic modular software for general tele operations scenarios. 
Separating the human/computer interface, the computer/computer interface (intermediate 
language) and the computer/instrument interface, permits application to different experiments 
and new experiments with minimal software development. 

Ada is an excellent choice as the standard programming language for telescience 
applications. This is primarily due to the exception handling, privacy, and multi-tasking 
capabilities, which are not available in other high level languages. Also important is the 
structured programming basis, which greatly simplifies team software development, 
debugging and documentation, and re-use by third parties. 

The University of Colorado has developed a prototype software package, called OASIS, 
for use in controlling and monitoring space operations activities. This OASIS prototype has 
been successfully used as part of a number of lab science testbeds with the following results: 

1. The capabilities provided by OASIS (user interface, experiment control, 
monitoring and communications) are essential to teleoperations. 

2. The ability to easily tailor the OASIS for new experiments and user interface 
has provided some TTPP user groups with a common tool for telescience that 
could be used early in their testbeds and can be enhanced throughout. 

Crew Interaction 

It is required that the PI and crew train in their operating environment. Almost every 
life science experiment requires extensive crew interaction as operators and, many times as 
subjects. Recognizing that the crew will not be as knowledgeable as the PI, it is crucial that 
they at least share a common pool of knowledge. Crews need to train together to form a 
rapport and a style of working together. Surveillance video and full duplex lines, with crew 
hot mikes and dedicated loops are required for efficient crew-PI interaction. 

The Ames Life Science Testbed involves one flight crewperson, one ground controller, 
who also serves as cap com, and one expert plant biologist. Crew interactions are facilitated 
by the medium resolution, color TV systems available which provide wide field of view 
coverage. In addition, having adequate light level makes it possible to see facial expressions 
in a natural manner without unnatural shadows, the audio system which allows all parties to 
be recognized by their voice qualities rather than have to identify themselves each time they 
speak, and by their capability to call upon one another for information as soon as it was 
needed. 
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Remote Operations 

It is in the best interest of the science community to design experiments which are as 
autonomous as possible, so that valuable crew time is well spent on those experiments and 
procedures which absolutely require crew support. The use of robotics and the telescience 
concept is one solution to this potential shortage of crew time. 

Experiment preparation (i.e., equipment warm-up, pre-experiment calibrations, etc.), 
shutdown (calibrations, turning off equipment), and periodic housekeeping (cage cleaning, 
equipment or environmental monitoring, maintenance), among other activities, can be 
accomplished using autonomous “robots” controlled by the PI from a NASA facility or home 
institution using SSIS data/video/voice network links. Many experiments may need only 
occasional intervention from the crew; some can only be done by the crew (human 
physiological studies, for instance). But in all cases, crew time must be considered as a 
limited resource, as well as power, volume, and other resources. The use of robotics and PI 
direct command and control of experiment hardware to minimize the need for human 
intervention onboard Space Station should be advanced as a telescience and SSIS option. 

Remote operations can be made safe, effective, and robust by including proper sensors, 
safeguards and controls. This must be carefully considered early in the experiment design 
process. 

Scientists will eventually require multiple access to multiple experiments. Arizona has 
demonstrated the feasibility of this mode of teleoperation, but it is necessary to incorporate 
this in the hardware/software architecture from the beginning. 

Video 

It is anticipated that the video bit rate available to individual experimenters on Space 
Station may be severely restricted due to limitations of TDRSS and ground data networks. 
Hence the ability of the PI to perform a remote coaching function with decimated video 
images was made a focus of the MIT/KSC Telescience experiment. The Pis were given 
independent control of frame rate, resolution, and grey scale (“FRG parameters”) subject to 
an overall video bit rate restriction, which was systematically varied in different sessions 
from 12 Mb/sec to 50 Kb/sec. When monitoring the progress of crew activities, Pis 
invariably were willing to sacrifice frame rate in order to obtain at least 4-5 bits of grey scale 
and the maximum available resolution. The Pis found that they could “get along” at video 
bit rates lower than they subjectively “liked.” However, the true value of having full 
bandwidth video occasionally available to the PI for monitoring dynamic events was 
exemplified when it was retrospectively discovered that a sled stripe display had been 
consistently moving at the wrong speed through all the sessions thereby invalidating one of 
the experiments. The Pis felt that if they had been given occasional bursts of full bit rate 
video on demand, the display problem likely would have been discovered and corrected. The 
Pis can accomplish most surveillance monitoring functions using black/white, relatively slow 
scan video. Bursts of high frame rate, high resolution video are extremely useful as are video 
cameras which can be remotely aimed and focused. 
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The Ames testbed employed four medium resolution (400+ line) color TV cameras 
within the Ames Life Science Testbed. A fifth high resolution color CCD miniature camera 
was located on the arm of the robot inside the glovebox. AH required life sciences 
procedures were completed successfully using these five cameras. Two orthogonal cameras 
are needed within the glovebox since the arms and hands of the flight crewperson often 
occluded one camera’s view. Specimen illumination had to be diffuse and bright enough to 
provide sufficient camera depth of field. 

The video is considered absolutely necessary to the successful conduct of the Life 
Sciences since they permit the ground flight controller and ground expert to continuously 
monitor space actions and to identify moments of opportunity when new and unplanned 
activities are inserted in the protocol. A roving camera in space is felt to be important as 
well as a set of rigidly located cameras. 

Arizona demonstrated that color video feedback is absolutely required for a robot 
controlled fluid handling laboratory. Since these are high volume passive channels, they 
cannot be routed through the operations management system. Delays of less than 2.5 
seconds were required, as were multiple cameras with remote camera control. Commercially 
available data compression technology for teleconferencing should be applied. Required data 
rates range from 80 to 400 Kb/s per channel, depending on image quality and rates of motion. 

One of the major areas of concern which has been identified is the distribution of video 
information via the SSIS. SSIS requirements documents call for distribution of real time 
video information, and duplex video teleconferencing capability with Space Station. Real time 
video and teleconferencing capability are believed to be particularly important for crew-time- 
intensive experiments in the life sciences area. However, several significant obstacles to a 
full implementation of these capabilities are imposed by bandwidth and distribution 
limitations. 

Payload Design 

Throughout the hardware development stages of certification, verification, testing and 
integration, the PI should be able to monitor progress of the hardware remotely from a User . 
Operations Facility (UOF) or from a home institution using SAIS/SSIS video/voice/data 
network links. This includes teleconferencing for design reviews and teleoperation during 
ground hardware tests. 

Data Transfer Reliability 

The reliability of data transfer is very important in telescience operations. MIT/KSC 
testbed results indicate that a data dropout (on the order of a second) is tolerable and 
recapture of lost data in realtime operations is of little utility. Realtime operations are most 
concerned with realtime data. However, data recapture is very important in off-line data 
review. An archival facility is required to provide a complete data set for off-line data 
recapture, review and analysis during the mission. 
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The JSC testbed performed network analysis on DECnet (running on VAX 750, VAX 
785 and microVAX computers) to test non-transparent task-to-task communication. Six 
network configurations were tested to evaluate performance with respect to data transfer 
rates and CPU consumption. Effects of buffer size on overall throughput and the effect of 
multiple logical links on data transfer rates were also examined. 

Existing SPAN and local networks can support low data rates (up to 9.6k or 56k) 
without dropouts only if network overhead and traffic is not excessive. SPAN and local 
networks were found inadequate for the JSC experiments due to excessive delay and packet 
loss caused by excessive network traffic. 

Distributed Software Development 

An essential requirement for distributed software development at MIT was the 
establishment of interface control documents (ICDs). ICDs baseline the system interface 
requirements and facilitate the integration of dissimilar distributed systems. It is essential 
that the interfaces specified must not be hardware or software dependent to enable specific 
systems to be tailored to individual needs. Standards for user interfaces are required to 
facilitate commonality (and hence user friendliness within the telescience user community). 
The resources for the KSC-to-MIT data communications system required linking an IBM PC 
386/MSDOS system using custom ASYST software with a DEC microV AX/Unix system 
running a custom C program. Establishment of an interface control document enabled 
successful distributed software development and integration of these dissimilar systems. 

Successful completion of the Arizona experiments would have been impossible without 
distributed software development by many members of a team and by teams at several 
institutions. The Ada software environment was important to the success of the Arizona 
experiments due to its portability across computer hardware and its programming support 
tools for standard documentation and structure checking. Network communications, with 
capabilities determined and driven by experiment function, are essential to experiment 
success. 

Colorado learned that it is important to have a clear understanding and documentation 
of the interfaces between distributed software components, standard (preferably Space 
Station standards) formats and protocols for exchanging information over these interfaces, 
and making sure that information passed over these interfaces is adequate. 

Expert Systems/AI 

The application of expert systems for telescience has progressed slowly over the past 
year due to the total lack of experience with the use of such tools. The telescience testbed 
activities have indicated several areas where Al/expert system tools could benefit from 
telescience operations. 

An target application was enabling of astronauts as science collaborators during the 
conducting of a space experiment. AI techniques are applicable to planning, operation and 
analysis. MIT’s “PI in a Box” program determined that the areas in which an on board 
expert system is useful are: 
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• remote coaching 

• signal quality monitoring 

• quick look signal analysis 

• interesting-case detection 

• experiment replanning 

An initial prototype based on the Space Sled showed the feasibility of the 
diagnosis/trouble shooting and the difficulty of classification of interesting data on-line. 

The first application is related to the teleoperations phase where scientists have expert 
system support tools to plan, replan and make realtime decisions during the operation of a 
space experiment. The MIT “PI in a Box’’ concept is such a knowledge-based support tool. 

The second application deals with the creation of expen system tools to assist 
scientists in the capture, storage, retrieval, and analysis of geographically distributed 
information residing on heterogeneous hardware and software systems. It required the 
development of knowledge bases containing information on network interfaces and protocols, 
database architectures and formats, and display formats and analysis/decision support 
choices. The complexities of such systems should be made to be completely transparent to 
the scientist, thus, insuring that the support tools will be efficient and productive parts of the 
operational system. 

Data Interchange 

The proposed networking methodology for telescience is currently based on the NASA 
Science Internet (NSI) plan. This implies standard protocols (currently TCP/IP migrating 
toward OSI) and either NASA provided long-haul links or other existing network 
connections (NSFnet, ARPAnet, etc.) to connect Local Area Networks (LANs.) Concerns, 
both technical and political, about communication link security need to be identified and 
subsequently addressed. This investigation includes the evaluation of encrypted existing 
networks versus dedicated NASCOM links to provide secure PI access to the flight 
laboratory. 

Life Sciences advocates adoption of the Consultative Committee for Space Data 
Systems (CCSDS) recommendation for the implementation of a standard data structure for 
the purpose of interchanging data in a uniform and automated fashion within the science 
community. The CCSDS recommendation defines the Standard Formatted Data Unit 
(SFDU) structure and construction rules that can be used to build the aggregate structure. 
However, additional structures and rules must be defined to address data interchange, 
archiving, and acquisition problems specific to the life sciences. 
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The JSC testbed used serial simulated and previous (recorded) unformatted experiment 
data, converted to Standard Formatted Data Units (SFDUs) of up to 64k bytes. At the next 
level of processing, a SFDU is encapsulated in a data packet according to telemetry packet 
standards promulgated by the CCSDS, standards which are being adopted by the Space 
Station Freedom Program. 

CCSDS data packets were transmitted to a remote node over several existing 
networks (notably the Life Sciences Data Distribution System), received in sequence, and 
stripped of their SFDUs for data processing. Software requirements are minimal, however, 
processing times may impact realtime data requirements. 

Arizona demonstrated that the Standard Functional Data Unit (SFDU) and CCSDS 
packet formats were sufficient for the data exchanges necessary for two teleoperation 
scenarios. They recommend that these international standards be required for all 
applications. 

The Colorado experiment came to the following conclusions: 

• The CCSDS telemetry/telecommand packets worked successfully. They can 
substantially increase the flexibility and capability of instruments. 

• Use of Standard Formatted Data Units (SFDUs) for telemetry data increased 
an instrument’s flexibility by providing self-identification of packet contents. 

• Using SFDUs to encapsulate and identify uplink data are useful and will likely 
help simplify complex command and control environments like Space Station. 

• Test of SFDUs for transfer of data from archives will be hampered by the lack of 
SFDU handling software and support systems. These tools need to be 
developed and evaluated. 

Distributed Program Management 

The MTT/KSC testbed found that to coordinate work between participants in distributed 
locations required four different communication levels. 

• Project Definition Document - Document to provide participants with the 
objectives, methodology, and actual implementation of the testbed experiment. 
Document was used as a reference to insure that the testbed was proceeding as 
required. 

• Telecons - Status of the testbed at each location was exchanged. A weekly 
telecon which included a review of an action item list provided all parties with 
information on the testbed status. 

• E-mail - Persons working on a specific action item maintained status between 
telecons using e-mail or the telephone. The important issue was to provide 
everyone with the current state of testbed activities. 
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• Site Visits - To provide participants with a view of the complete picture of the 
testbed, reciprocal visits to each site were in order. The MIT/KSC testbed found 
these visits necessary to understanding the logistics problems involved and the 
location’s capabilities. These visits were also useful in assuring that the 
Project Definition Document was being adhered to. 

Operations Management 

Colorado found that the enabling technology for distributed operations is transactions 
management. Key capabilities include command interlocking and reactive control. These 
capabilities have been implemented in a Colorado testbed and shown to work in protecting 
the health and safety of experiments and space subsystems. 

Another operations management capability includes control and management of user 
access of experiments, systems and tools. In initial tests the CCSDS protocols for access 
control seem adequate. 

The Colorado tesbed demonstrated that the onboard operations management 
capabilities should be distributed to the various distributed onboard instruments and 
subsystems. 

Training and Documentation 

The MIT/KSC testbed provided substantial crew (EPS) training on sled operations and 
experiment procedures. The Pis were not trained on the sled operation procedures. To 
increase the monitor/maintenance capability of the PI, for testbeds as well as space 
experiments, training for experiment hardware operations should include both crew and PI. 
The crew and PI training should be focused on the experiment hardware 
operation/maintenance/safety with the PI training also including work with the PI 
workstation. 

Experiment procedures were maintained throughout the testbed which provided a script 
for each experiment session. A well maintained set of procedures will facilitate good Pl/crew 
coordination during experiment operations. 

Workstation Hardware 

The MIT/KSC testbed PI workstation was implemented using a networked DEC 
micro VAX II with a Parallax video board. The DEC microVAX II supplied the data 
processing and display while the parallax board processed the video signal for display on the 
microVAX display monitor. The Parallax board function was found to be sensitive to video 
signal content. 

The testbed found that one microVAX II was not capable of handling the entire 
processing load, and reduction of the data set was necessary for the one microVAX n. To 
improve data handling capabilities required distributed processing to other computers. 
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Among the workstation displays which were considered particularly effective during the 
Ames Life Science testbed is a large format (26") high resolution color (composite) monitor 
which presents imagery from four TV cameras simultaneously via a “quad splitter” to the 
ground crew. Ground crews find their eye scans to be shorter and faster than if four 
separated monitors are used. A one second accuracy digital time (and date) is also 
displayed. A video switch makes it possible to view the output from other cameras as well 
(e.g., from the ground expert location). Each participant wears a wireless headset and boom 
microphone at all times which frees up their motions. 

A Macintosh computer is installed inside the glovebox. It is used to present various 
experimental procedural information both visually and orally (using a voice synthesis). 
Directly above the computer screen is a high resolution, color monitor which is driven by the 
TV camera located at the ground expert’s site. Both items are used in coaching of unplanned 
test procedures; both are found to work well. 

The Ames testbed incorporates Macintosh ITs, an Everex 386, an IBM PC and a 
microVAX GPX. The Mac Et/HyperCard provides the most flexible, visual and powerful 
prototyping environment. 

Arizona found out that microVAX II GPX or equivalent was useful for various 
teleoperations applications. Local controlling computers can be smaller and do not require 
color graphics displays. 

The Colorado group has successfully implemented the OASIS teleoperations package 
on both the microVAX and Sun workstations. 

Software Packages 

MIT/KSC utilized the X Windows graphics standard for software development, 
including a special MIT project, Athena driver, supporting realtime windowed video. KSC 
employed the ASYST data acquisition/communications software package with their PC 386 
system to support data acquisition/communications between KSC and MIT. Use of ASYST 
facilitated rapid development of a flexible data acquisition/communications system. Although 
the data analysis capabilities of ASYST were not employed in the phase 1 testbed effort, 
this capability could be used to explore flight workstation requirements. The advantages of 
using off-the-shelf hardware wherever applicable is demonstrated by experience. 

The Ames testbed used the following packages: OASIS, adaptations of public domain 
communication packages for the Macintosh n, a public domain speech synthesis package for 
the Mac, and Scorbase, a robot programming language. The Meridian Ada compiler is used 
on the PC’s and Macs. All of the above proved satisfactory. 

OASIS proved to be very useful as the human/computer interface. The modularity of 
OASIS should be extended in future releases to allow it to be useful for a larger range of 
teleoperations applications. 
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Telescience Science Productivity 

Seven of eight experiments performed by the MIT/KSC experiment were judged by the 
Pis to have been greatly improved by the telescience concepts. Noticeable were a reduction 
of wasted time, increased crew/PI coordination and rapid problem detection/resolution as 
compared to a “negative reporting” environment such as used in operational 
shuttle/spacelab missions. This increase in science productivity resulted from increased 
audio, video and digital data delivery to the PI. 

Effective automation and remote operation saved crew time and training in the Arizona 
testbed. In this experiment, much of the work involved tedious and repetitive fluid handling. 

The Colorado telescience approach increased scientific productivity by: 

• Enabling science experiments to be performed that were previously impossible 
or impractical. 

• Allowing more scientists and students to participate in space experiments. 

• Better utilizing (through interactive operations) the most precious resource - 
spacecraft observing time. 

Knowledge Capture 

The Life Sciences discipline telescience experiments at Stanford have produced 
significant results which will directly influence the design of the space station and the design, 
operation, and analysis of life science experiments in the space station era. The telescience 
activities have indicated a need for a quantitative assessment of lessons learned. This 
quantitative assessment will enable a system-wide implementation process to occur which 
responds to each of the lessons learned. If support tools are available to assist in this 
assessment, they should be made available to all of the telescience discipline areas. 

User Interface 

The most important requirement is to have a consistent set of user interfaces. The MIT 
testbed required that PI workstations (NASA or user supplied) adopt standardization of 
interfaces to experiment information. 

Different levels of interaction are required. A casual user would use mostly high level 
(graphics, icons, batch commands) interactions and not need to know, for example, 
programming language syntax. However, the programmer developing such an application 
should have access to all levels of interaction. 

Ames concluded that the Macintosh user interface proves quite useful for prototyping 
since the users are working with familiar metaphors. Interactions are further enriched by the 
Macintosh bitmapped screen, animation capabilities under HyperCard, voice synthesis, etc. 
Color and multiple windows provide significant advantages. 

Colorado’s observations on user interface are as follows: 
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• The Macintosh-style of user interface provides a good basis for a useful 
interface. This interface style has been used and successfully demonstrated in 
the OASIS . 

• Users are happiest with an interface that they have been able to mold or tailor to 
their own specific needs. This ability to easily tailor an interface by an individual 
user is a needed feature, within the constraints of the relevant standards. 

• Users would like to be able to directly manipulate an icon as a control directive 
rather than use indirect control techniques such as typing instructions on the 
keyboard or going through menus. 

• User interfaces should be set up to give the users the feeling that they are 
manipulating the process (or experiment) itself and not just manipulating the 
screen. 

Pre/Post Flight Data Collection 

The PI will monitor baseline data collection from the BCDF via SAIS/SSIS 
video/voice/data network links to both the BCDF and the DOC; this is for both pre- and 
post-flight baseline data collection. (DOC personnel will also monitor progress at the BCDF 
via the same links). Prior to and just after flight, the PI at the UOF (and personnel at the 
DOC) will monitor experiment status as hardware and specimens go through the Life 
Sciences Support Facilities. In-flight operations (manned base and shuttle) will be 
monitored by the PI at the UOF, as well as at the DOC, POIC, SSSC, and the ESC. Through 
the DOC, the PI will have the ability to request experiment timelines and resource 
allocations. Data and experiment status will be provided according to the grade of service 
requested (i.e., realtime, no bit drop-outs, once a day, etc.) 

3.4, Microgravity Sciences Summary 

The following paragraphs summarize the data and recommendations resulting from the 
efforts of the teams at the University of Arizona and Rensselaer Polytechnic Institute. These 
efforts were directed toward the study of the telescience (teleoperations) concept in the area 
of microgravity science. At Arizona the thrust was toward remote fluid handling and at RPI 
it was toward microgravity materials science. A commonality of requirements developed 
from these experiments and these are discussed in the following material. 

Scientific Productivity of Telescience 

The key contribution to scientific productivity through telescience is characterized by 
the words “rapid feedback.” The results of an experiment will be known to a principal 
investigator on earth as the experiment proceeds. Thus the experimenter is able to act much 
as in his/her own laboratory and react to unexpected results or make modifications to the 
experiment or redo the experiment as the data demands. 
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Experiment Equipment Design 

Payload design is affected significantly by the desire and capability of the earth bound 
investigator to perform as extensive and rewarding an experiment as possible while in the 
microgravity environment. With live data available and the ability through fixed automation 
or robotics, the PI can physically reconfigure the experiment. Clearly the payload itself and 
associated instrument packages must be compatible with the degree of automation provided. 
In liquid handling, for instance, the need for parameter adjustment based on measured results 
demands fluid transfer in a closed container to avoid liquid-air interfaces. Both the 
experiment and the associated instrument package must be designed to be compatible with 
the indicated demands of microgravity and the handling equipment, in this case a robot. 

Information Transfer Reliability 

Information is transferred to the platform from the ground in terms of control signals. 
These control signals may be of vital concern to the outcome of the experiment, and require 
conventional error checking and probably limit switch type of mechanical protection in case 
the wrong signal was sent and incorrectly checked. 

Return data requires no more reliability than is presently demanded, and perhaps less, 
as the PI may review the data as received. 

Planning and Scheduling/Operations Management 

Since the general concept of telescience includes the concept of distributed experiment 
control it requires a well defined operations plan. However, this plan must be responsive to 
hour by hour changes. A central operations planning center is required and voice and E-mail 
circuits must be available to all remote control sites. In addition all commands issued by the 
remote sites must funnel thru this center for validation and relay. This center must be 
responsive to science requirements (i.e.. windows of opportunity) as well as flight 
requirements (i.e.. crew availability) to maximize the scientific productivity. 

Video/Imagerv Requirements 

For a remote experimenter to control his experiment it is required that some form of 
visual information be available to him. For the purposes of this study only the requirements 
for control (not data) were considered. A review of potential Space Station microgravity 
experiments indicates a wide range of requirements. From a minimum of black & white, low 
resolution (128 x 128), and low frame rate ( 1 frame per minute) to a maximum of full color, 
media standard, systems may be required depending on the specific experiment. 

Voice and Data Transmission Requirements 

For those experiments requiring crew assistance at least one dedicated, direct, voice 
channel is a definite requirement during the periods of crew involvement. Uplink and 
downlink data/command channels are also required. Bit rates from 16 to 64 KB/sec are 
required depending on the experiment. Anticipated data transmission problems, i.e.. Z.O.E., 
dropouts, and moderate latency will not preclude the telescience concept. 
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User Interface with Computer Control Console 

In this concept it is planned that the control of the experiment may be by a scientist 
who is not completely comfortable with a computer console. For this reason the interface 
must be “user friendly”. Operation must be simple, goof proof, direct and clear. The 
lessons learned in developing programs such as “OASIS” can be utilized in the creation of 
software for this purpose. 

Other Ancillary Requirements 

In addition to those discussed above there are other requirements which are less 
important but nonetheless needed. These include: 

• Remote coaching, monitoring and maintenance 

• Remote databases 

• Training and documentation 
Summary 

Although further experimental work is needed to determine realistic numbers for 
specific requirements, a large gain in science productivity can be achieved with capabilities 
as given. It is apparent that, although not all microgravity experiments are amenable to the 
telescience (teleoperations) concept, a large proportion appear to be and the required effort 
can be justified there on. 
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Section 4 

Results and Conclusions 

In this section, the results of the testbed are integrated across the various disciplines. 
They are described in terms of the three aspects of telescience; design, operations, and 
analysis. In addition, lessons learned regarding infrastructure and programmatics are 
described. Because of the similar requirements of design and analysis, they are described 
together. 

4.1 Design and Analysis 

The design and analysis phase of research often involves many participants working 
together with remote databases, design aids, and testbeds. Often equipment must be located 
remotely from the scientist or developer. Debugging software remotely is extremely 
valuable from several points of view. Observatories are remote, and it is not possible to 
have all the team together at the site. During the TTPP, a programmer was able to remotely 
debug software. This saved significant travel funds; current network capabilities worked in 
this instance. 

In terms of hardware design for Space Station and related systems, engineering studies 
are now in progress at a number of universities and contractors. Tying all these diverse 
groups together is a very hard problem. One of the key problems is the lack of knowledge of 
the design documentation trail. A bulletin board mechanism plus appropriate database and 
document retrieval components is going to be vital. However, documents are not in standard 
formats (Macintosh vs. VAX vs. ...), and graphics interchange standards are not in place in 
the community. Further, exchange of the underlying design database is sometimes needed 
(i.e., interface specifications documents). Overall, it is difficult to get all the groups working 
to the same set of specifications. 

In the MIT/KSC life sciences exeriments, approximately half the anticipated number of 
experimental sessions were possible. Program-level problems included funding delays, 
getting communications lines bought and installed, and frequent revisions to the early 
system definition document. FAX was found to be very helpful. Further, the lack of 
networking literacy was a problem at the beginning of the program. Within the experiments 
themselves, it was not possible to look at the ‘zero latency’ condition during the testbed 
condition. NASAselect was used for video, but the low priority assigned to use of the 
system for the testbed program hurt both scheduling and science. 

We don’t generally have adequate methodologies for examining results of teledesign in 
the testbed, particularly when people are at both ends (human factors). Multimedia 
mail/conferencing have just scratched the surface. There is no tool for rapid prototyping of 
virtual instruments. Given the multi-year distance between engineering questions and real 
experience in science use of the resulting systems, the design process must provide tools for 
Pi’s to be able to modify things. A Mac running LabView worked well for some kinds of 
science. Other cases exhausted higher-end workstations. The lesson we draw from this is 
that the PI workstation is a generic idea with a wide range of possible capabilities. 
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Portability was found to be extremely important at multiple levels: workstation 
software level, as well as design documents (both text and graphics). 

Information overload was clearly identified for the Pi’s in real time operations. A hard 
copy log book was vital to the experiments. Based on these experiences, more effort must 
be expended to automate the logging process. Statistics such as ahead/behind schedule, 
checklists, and a database of normative data would all help. 

In some of the experiments there was minimal need for teleanalysis during operations, 
because the science team was just too busy. 

We underestimated the time the PI team took to learn the tools created for them. Thus 
there is a big premium on user friendliness (i.e. choosing text editor for log function familiar 
to the scientists). 

Ada was viewed favorably by the system developers who are using it. Problems with 
real-time capabilities have been identified. 

A toolkit for the design of the tlser interface should be available to the PI - intensive 
interaction with high fidelity to the environment is very useful to design the user interface to 
the systems. Rapid prototyping tools are essential so that the contractors and system 
implementors converge towards a useful system, rather than the traditional specification => 
implement in isolation => hand off system to users. TAE+ was found to provide a good set 
of tools according to one experience in the program. 

The experience of the group suggested a strong need for trade-off studies and 
simulation tools (such as robot setup vs. software simulation) in the design phases. 
Contrasting the time available for experiments (whether on shuttle or on station) vs. 
astronaut time vs. teleoperations capabilities vs. autonomous operations was not possible, 
although very important. In a specific example - is a robot in the glovebox useful, when the 
glove box is the point where the astronaut works with the equipment and samples? That is 
the baseline design and the Pi’s aren’t sure it’s the best way to go. Is the scientist’s lab on 
earth a good model of the spacebome laboratory; is it a reasonable parallel? Can a 
prototyping lab for materials & life sciences be developed to get more experience for the 
science projects? Such a lab would be a place where a PI can come in with a surrogate crew 
and his/her specific equipment, and optimize the experiment itself as well as the bandwidth 
use, etc. The proposed science and technology centers are an excellent concept, particularly 
if they can be used not only in verification of the instrumentation but also in design of the 
experiments themselves. 

An observation many of us made is that we have limited experience with video 
teleconference, and thus cannot compare it with the multi-media mail/conference systems. 
Voice teleconference and fax were useful during several of the experiments during both 
design and analysis phases. We suggest that NASA’s teleconference services be made 
available to the team as a near-term facilitation of the program, as well as to evaluate utility 
of the teleconferencing mode for operations. From another point of view, how do we find out 
about some of the private and public sector efforts in these areas, for example, where 
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networked workstations were used in design experiments, the application of relatively older 
technology like slow scan TV for teleconferences (for block level design meetings, and for 
coaching), etc. 

The group is concerned about standards issues in both design and analysis. We 
recognize that standards are both a blessing and a bother- the standards must facilitate the 
work rather than hinder the developments. Standards areas such as windowing 
environments (i.e. X-windows), communications (TCP, ISDN), and operating environments 
(POSIX) are useful; we have less of a coherent idea about standards for the user interface, 
standards for dataset formats themselves, and so forth. 

Several groups observed that there are different levels of service required to support 
interaction with remote archives. Simply locating interesting data (perhaps by query of a 
database system) is accomplished reasonably well with 9.6 kb dial access, and the Internet 
is not bad for subsequent background data file transfer. 

When the goal is to view data, on the other hand, the acceptable time scale for a 
graphic screen display for this kind of retrospective analysis is on the order of 0.1 to 1 
minute, almost irrespective of the characteristics of the data (raster vs. vector, color vs. 
monochrome). This provides a mechanism to compute required throughput for some classes 
of operations. We also recognize that there are all kinds of trade-offs between pre- 
processing certain predefined products vs. on-the-fly computation based on real-time 
demands, as well as the use of data compression. 

There were some group analysis workshops during the program, which typically meant 
getting the team together at a single site. There is great interest in geographically 
distributed work group analysis proceeding relatively in parallel, rather than sequentially, but 
we have no experience in this specific mode. The remote coaching type system seems a 
natural support mechanism for multiple scientists accessing processing systems 
simultaneously for collaborative analysis, but we were unable to exercise such a system. 
Remote access to processing capabilities requires support functions in terms of documenting 
the available systems and software, guidance in use of the systems and so forth, this is the 
same as the supercomputer center experience in many ways. There was relatively little 
teleanalysis in this mode, since the documentation, accepted data and interface standards, 
and support were unavailable. 

There are several important standards areas we have recognized (principally from an ' 
image data viewpoint, but we believe these are general): Descriptive standards (the 
syntactic and semantic contents of catalog/inventory /directory), vs. Data format standards. 
We are in agreement that standards for description of the format - in effect, an envelope 
around the dataset - are more useful to the community rather than specifying the physical 
format a priority. 

These become even more important as we begin to develop the level 3 and level 4 
derived products from future systems. These also are important within programs for local 
datasets and archives, to not lose the value of the data through time (self described datasets 
may still be useful after the person who collected them leaves the center). 
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4.2 Integrated Results on Teleoperations 

This section integrates the results of TTPP across the science disciplines with respect 
to teleoperations. 

The Teleoperations Paradigm 

In order to discuss teleoperations results, it is useful to first define a teleoperations 
paradigm. Teleoperations is the concept of operating a laboratory remotely by providing the 
capability to interact with remote instrumentation as if those instruments were contained in a 
local laboratory. In addition, teleoperations enables the conduct of interactive science where 
the immediate results of an experiment can be evaluated by an investigator and can be 
refmed iteratively, or new experiments can be conducted in response to the measurements. 
Teleoperations optimizes science return by enabling users to make efficient use of time and 
resources. Central to the concept of teleoperations is the realtime delivery and analysis of 
both telemetry and science data to the scientists conducting the experiment, in order to 
evaluate the status of remote instruments, and to assess the performance of the science 
experiments. Of equal importance is the ability of the scientist to control remote instruments 
interactively. 

In the ideal case, teleoperations would permit a scientist at his or her home institution 
to conduct an experiment remotely using realtime displays of the science and telemetry data 
and interactive control of the instruments within limits imposed by resource constraints, 
security, and safety. 

Our teleoperations concerns can be summarized as follows: 

• To what extent should instrumentation be controlled from a centralized NASA 
operations center, and what capabilities can be distributed to the science users? 

• What level of interaction by a science user is needed for effective science 
operations? What functions should be reserved for a central NASA control 
facility? 

• What is an appropriate mix between automated and manual operation of 
experiments? 

• What command interlocks are necessary for hazardous operations? 

• How should resources be allocated, and can the concept of resource envelopes 
be used successfully to manage shared resources? 

• How will communications, data and control interfaces and protocols be 
standardized? What are appropriate standards for common user interfaces for 
workstations? 

• How can instrumentation be shared by different experiments and by different 
scientific disciplines. 
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• How are changes in procedures handled with regard to safety? What latitudes 
should scientists have in modifying their experiments? 

We have learned some valuable lessons in teleoperations from our TTPP experiments. 
These lessons are listed here and described in the following paragraphs. 

• Workstation Standards 

• Communication Needs 

• Video Requirements 

• Operations Management 

• Teleoperations Through the Project Lifecycle 

• Increasing Science Productivity 
Workstation Standards 

The human/computer interface for teleoperations should allow for: 

• Ease of use 

• Consistency 

• Reliability 

• Adequate computational power (minimum latency) 

• Coherent interfaces regardless of the location of the human operator (IVA 
workstation, EVA workstation, ground-based) 

• Flexibility of input and output devices 

• Sufficient monitoring information for control 

• Flexible (user adjustable) screen display 

A compromise must be found between standardization and flexibility of the user 
interface to the needs of the particular application. Some details of the user interface may be 
application dependent, but the meta-interface (“touch and feel”) should be common 
between applications. 

Among all the possible hardware/software configurations, all TTPP participants chose 
either Sun workstations or microVAXes, and either UNIX or VMS. While this decision was 
certainly dictated by the current market situation, and may change between now and the 
launch of Space Station, it was commonly agreed that the chosen hardware/software 
systems were adequate for the TTPP tasks investigated. 'While a number of TTPP 
participants complained about the realtime performance (execution speed) of their chosen 
workstation environments, nobody complained about the adequacy of the way in which they 
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were forced to interact with their experiments through their workstations. From this, it can 
be concluded that the selection of ONE human/computer interface environment for 
teleoperations (for the purpose of standardization) is more important than the detailed 
specifications of how exactly this interface looks like, as long as the interface provides for an 
appropriate balance between standardization and flexibility. This indicates that selection of 
a commercial off the shelf hardware/software configuration may be justified. 

Several TTPP participants had a chance to acquaint themselves with OASIS. It was 
generally found that the OASIS “touch and feel” characteristics provide for a satisfactory 
balance between standardization and flexibility. The workstation latency of OASIS in its 
current implementation is still a little too long for use in high data rate Space Station era 
experiments, but faster workstations will be available by then. Users have also 
recommended that OASIS be enhanced with respect to its communication capabilities 
(communication between multiple remote experimenters, and communication with the 
experiment itself). OASIS proved to be adequate for the uplink of telecommands and 
handling of moderate data rates, but is still somewhat too slow for handling large amounts of 
incoming telemetry data. Finally, the development of new OASIS application databases 
could be made more user friendly by a TAE+ like front end for the purpose of interactive 
screen design. 

Communication Needs 

The following communication parameters are of importance to teleoperations: 

• Bandwidth 

• Connectivity 

• Latency 

• Phasing 

Results from TTPP indicate that the tolerable maximum values for these four 
communication parameters are discipline- and application-specific. However, some common 
lessons were learned. 

• Bandwidth: The overall required space-to-ground bandwidth will be larger than 
the overall required ground-to-space bandwidth. The realtime space-to-ground 
bandwidth requirements are more stringent in life sciences and microgravity 
sciences than in astrophysics and earth sciences. This is due to the fact that 
realtime data delivery is an absolute requirement for life sciences and 
microgravity sciences, but for astrophysics and earth sciences longer delays can 
be tolerated. Space-to-ground bandwidth requirements are largely dictated by 
the needs for video-feedback. Such needs were reported from all science 
disciplines. Full ground-to-space bandwidth is desirable, i.e., NASA should 
provide for capabilities of video transmission from the experimenter’s ground 
laboratory to Space Station for remote coaching. 
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• Connectivity: Universal connectivity is desired. Connectivity actually covers a 
variety of different aspects: 

- Connectivity between several geographically separated experimenters — 
there are needs for fast on-line communication between several ground- 
based centers. 

- Connectivity between the scientist on the ground and the astronaut — there 
are needs for both video and audio communication during the conduct of an 
experiment. 

- Connectivity throughout the experiment — reliable connections are 
mandatory for most remotely controlled experiments. 

- Connectivity for longer periods of time — the 10 minutes zone of exclusion 
when Space Station is hidden from both TDRSS satellites poses a problem 
to researchers from most disciplines. 

• Latency: Latency is a crucial parameter to teleoperations. A precise value for 
maximum tolerated latency is application specific. Microgravity and life sciences 
seem to place the most stringent requirements on latency. Some applications 
can live with a maximum guaranteed latency of 5 seconds, but some applications 
require a more immediate turn-around. Microgravity sciences expressed the 
requirement for 2 seconds latency. 

• Phasing: Phasing is important for combined video/audio feedback. It is 
anticipated that the audio link and the video link might use separate paths 
between Space Station and the remote experimenter. In this process, a phase 
difference between the two signals may be introduced. Although this parameter 
was not studied extensively by any of the TTPP sites, preliminary 
investigations from RIACS seem to indicate that any phase difference of more 
than 2 seconds between audio and video signals leads to confusion. 

Video Requirements 

Recommendations from the TTPP investigations for video requirements include 
downlink and uplink video capabilities as well as certain video hardware placement. 

• Downlink Video: Downlink video should be provided to the investigator’s 
remote site. The downlink video will provide the investigator with the 
information necessary to monitor experiment progress and crew interaction 
which will increase the scientific productivity and efficiency. Full bandwidth 
capability should be available at the remote site when needed. Investigator 
selected frame rate, resolution, and gray scale enabling the PI to establish the 
“best” picture for his or her needs according to the current bandwidth allocation 
appears to be desirable but needs further investigation. This selectability is 
important because the Pi’s “best” picture may change during different 
experiment phases. The latency and phasing requirements for video need 
further investigation to determine the acceptable levels. 
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• Uplink Video: Uplink capabilities are needed from the remote investigator site 
to the instrument site. This capability provides the opportunity for remote 
instruction for problem-solving, crew training, and remote coaching. Since 
certain experiments will require interaction with crew members, and since 
certain experiment results may dictate a change in procedures, uplink video may 
be critical in re-training. The bandwidth, latency, and phasing requirements for 
uplink video have not been determined and should be investigated. 

• Hardware: The video cameras/optical lenses needed to monitor an on-going 
experiment will be largely experiment specific. However, cameras will also be 
needed for crew interaction, for monitoring the experiment setup, and for 
monitoring laboratory animals. It is recommended that movable cameras be 
provided. 

Operations Management 

A common lesson learned is the fact that teleoperations is concerned with much more 
than getting a command across from one remote experimenter to one onboard instrument, 
and getting telemetry data back to the remote experimenter. 

These additional complications have to do with the fact that in reality a multitude of 
remote experimenters will wish to simultaneously gain access to a variety of different 
instruments using common communication channels and common resources. 

In the first phase of TTPP, not enough time was available to investigate all key aspects 
of teleoperations, aspects which require more and expanded testbeds before a final 
assessment can be made. Some of these aspects are listed below. 

• Distributed Planning and Scheduling: The remote control (teleoperation) of 
equipment and experiments onboard a Space Station era mission must be 
properly planned and scheduled in concert with other on-going activities. 

Several experimenters may need access to shared instruments, one 
experimenter may need simultaneous access to several instruments, and 
several experiments may share a common resource such as electric power. 

• Rescheduling: Resources may have to be quickly rescheduled in response to 
unexpected problems or opportunities. 

• Operations Management: Future operations systems must include techniques 
for command .interlock to prevent potentially dangerous operations from being 
executed, and reactive control to react to situations where an instrument or 
experiment is interfering with other operations by using more than its allocated 
share of resources. 

• Access control: A technique should be demonstrated that grants authorized 
users access to their experiment resources while preventing unauthorized users 
from having such access. 
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Teleoperations Through the Project Lifecycle 

Design for teleoperations should include not only provisions for remote control of 
instruments during experiment execution, but also for calibration and maintenance of 
instrumentation throughout its lifecycle of development, test, integration into the Space 
Station, and operations. These provisions need to be fully explored and demonstrated in 
future testbeds. 

• Calibration: Remotely controlled experiments should in general also be checked 
out and calibrated using the teleoperations approach. 

• Automatic Shutdown: If connectivity is lost during a test or during the execution 
of an experiment, each teleoperated experiment should provide a means for a 
safe and automatic transition to either a waiting state or a fully automated 
continuation. The implications of this need to be further testbedded. E.g., it may 
be necessary to request that this transition be handled in a decentralized mode 

by each instrument computer independently. If the connectivity through the 
TDRSS satellite is lost, all teleoperated experiments will have to go 
simultaneously and quickly through this operational phase, and the Space 
Station OMS may be unable to handle all these requests in a centralized manner. 

• Remote Recovery: After connectivity has been reestablished, it should be 
possible to reactivate the experiment through teleoperation. 

Increasing Science Productivity 

One of the many positive lessons learned during the testbed was that teleoperations 
increased science productivity at all levels. In this section, we shall summarize how science 
productivity can and has already been improved through teleoperations. The specific 
parameters which contributed to increased productivity are discussed below. 

• Distributed Resources and Resource Sharing: Tele operations allows the PI to 
assemble the needed manpower and other resources without having to pay for 
travel and equipment shipment. Resources include everything from super 
computer time for data analysis to a telescope technician for remote 
troubleshooting. In some instances, gaining immediate access to a highly 
trained remote technician may be imperative to the success of the experiment as 
a whole. 

• Enhanced Instrument and Data Accessibility: By means of tele operations, both 
space instruments and scientific data can be made available to a larger body of 
scientists and science students. E.g., teleoperations has enabled the 
University of Colorado to redirect realtime data from astronomical observations 
into the classroom, and to design experiments interactively and on-line with 
student participation. 

• Rapid Access to Flight Data: Near realtime data retrieval permitted by 
teleoperations has numerous advantages which lead to increased science 
productivity. With rapid access to data at the Pi’s laboratory, the investigator 
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can perform near realtime data analysis using the hardware and software to 
which he/she is accustomed, and which have been customized for that type of 
experiment. Not only does teleoperations with realtime data increase the Pi’s 
knowledge of the progress of the experiment, but allows more realistic 
experimentation. For instance, on-line data analysis might show a particularly 
interesting event which needs further investigation. The PI can see the event 
occurring, and can request a modification in the experiment procedure to take 
advantage of the unexpected event. Off-line experimentation allows verification 
of hypotheses. On-line experimentation allows exploration of the unknown. 

• Direct Pi/Crew Interaction: The duplex voice channel and simplex video channel 
between the PI and the crew contribute significantly to the increase in science 
productivity. Audio communication promotes joint discussions of experiment 
progress, coaching of the crew during troubleshooting, and experiment procedure 
redesign during the experiment execution. This capability is most important in 
effectively using the time allotted for each experiment, and in redefining the 
schedule when unexpected events occur. “Open-mike” monitoring of crew 
conversations, as discussed earlier, hellp support effective Pi/crew interaction. 

Our work in TTPP showed an increase in science productivity as a result of improved 
communication links which allow video, audio, and data to be transmitted freely between 
participating nodes to provide the most efficient use of the allotted experiment time and 
resources. 

4.3 Integrated Results on Network Infrastructure 

Integrated results and recommendations regarding network infrastructure were 
addressed in three distinct operational contexts, as shown below. For the first of these, only 
the terrestrial network is involved. For the second, the uplink, relays, and onboard SSIS are 
also involved. The third may involve only the terrestrial network or the entire system, 
depending on the application. 

Telemanagement 

Telemanagement includes planning, scheduling, design, distributed program 
management, and operations management. 

It was unanimously agreed that this class of activity has been made much more 
productive by availability of network service. The results showed that such service would be 
significantly enhanced by “return receipts’’ to indicate delivery to the addressed host (not 
intermediate nodes) and by more timely advice of undeliverable status. Better information 
exchange between NSI/NSF/DOD network managers and users (introductions, primers, 
users guides, etc.) was also recommended. 

While electronic mail and file transfer services were mainly satisfactory, multimedia 
network capabilities were found to be inadequate. For the most productive planning, 
scheduling, design, and teleconferencing, an integrated service which provides voice, 
graphics, video, and text is required. 
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Most participants experienced some degree of information overload. It was suggested 
that display of detailed routing information be made a user option, and that formal network 
usage guidelines be issued to help avoid junk mail and careless use of address exploders 
(automatic distribution lists). 

Teleoperations 

For those functions which involve time critical monitoring and control, the results 
indicated that the required services included audio, command/ control/telemetry, and video. 
The audio channels each require data rates of 64 Kilobits per second (Kb/s) for nominal pulse 
code modulation of a 4 KHz analog channel. For speech channels, this can be reduced to 16 
Kb/s by using a linear predictive coding compression algorithm. It was demonstrated that 32- 
64 Kb/s was sufficient for the command/control/telemetry channels. Data compression is not 
recommended here for the sake of robustness. Arizona found that their video information for 
control of lifescienee experiments could be transmitted at 50-400 Kb/s (depending on 
required quality and rates of motion) by using commercially available compression 
techniques developed for video teleconferencing. If video comprises scientific data, much 
higher rates may be required. RPI used 512x512x8 bits per frame at 30 frames per second 
(7.8 Mb/s) for their microgravity experiment. Future use of high-definition television 
(HDTV) would require even higher rates. It should be emphasized that these rates are per 
channel. The experiments in the pilot program each used 1 or 2 audio channels, 1 
command/control/telemetry channel, and 1 to 5 video channels. 

Several requirements for maximum time delay (latency) were identified. All of these 
are round trip delay times which include the terrestrial network, uplink, relays, SSIS, and all 
onboard processing delays (for example those incurred in the operations management 
system). The astronomy, life science, and microgravity science experiments all showed the 
need for less than 1 second (or best available) time delay for over-ride control, and 5 
seconds maximum for normal operations (priority commands and status telemetry plus video 
feedback and starfield images of [64x64x16] bits). 

These critical services must be extremely reliable, and the maximum time delays must 
be guaranteed at all times except for scheduled outages such as zone of exclusion 
transitions. Current public access networks cannot provide these features. 

For noncritical monitoring and control functions the same kinds of channels and bit rates 
are required (perhaps fewer per experiment), but there are less stringent time delay and 
reliability requirements. An example of this would be a quick look at astronomy data of 
1024x1024x8 bits within 30 to 60 seconds of request. 

Teleanalvsis 

Much of the scientific data consists of images. In these experiments the image sizes 
ranged from 5 1 2x5 1 2x8 bits to 1024x1024x16 bits, and the generation rates ranged from 1 to 
10**5 frames/day. All other kinds of scientific data from the testbed experiments fell within 
these bounds. In the near future data from astronomy experiments is likely to be as large as 
4096x4096x24 bits (the same as color HDTV). This data must be transmitted to earth, 
distributed, and stored. The allowable time delays for return of scientific data were 
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extremely experiment dependent and ranged from near real-time to days. The integrated 
range of data volume, generation rates, and allowable time delays is very broad. The 
equivalent performance and reliability requirements vary from public network grade of service 
to PIOC-SS grade. 

Open Issues 

Several issues remain unresolved. 

• Which of the above needs require computer networks as they now exist, which 
require computer networks with priority scheduling (virtual circuits), and which 
require dedicated circuits? 

• The time delay requirements are quite stringent. How will overall system 
performance be verified prior to deployment? 

• What combination of on board storage, earth station storage, and verification is 
required for reliable return of scientific data? 

• Terrestrial distribution of large databases, long term analysis, and teledesign 
will ultimately require high capacity world-wide multimedia services not 
currently available. Required data rates will range from near 0 to more than 
10**9 bits per second. How will this be accomplished? 

4.4 Programmatic Lessons, Results, and Recommendations 

One of the major motivations for conducting the TTPP was to validate the rapid- 
prototyping testbed approach and learn how to conduct such a program. The TTPP and any 
subsequent rapid-prototyping testbed activity involves a large number of participating and 
interested organizations, ranging from technologists and users collaborating in the actual 
testbeds to the developers of the target system (e.g. Space Station and its associated 
information systems) and the NASA monitors, managers, and sponsors. 

The TTPP intentionally involved all such parties so that experience could be gained in 
how to manage and conduct such a program. This section contains a summary of the results 
and lessons of this aspect of the program. 

Contract Arrangement 

The TTPP contractual arrangement was to have a prime contract with the USRA who in 
turn subcontracted with the various University participants. USRA provided technical and 
administrative management functions, coordinating and integrating the various activities. In 
addition, related activities at several NASA centers were funded directly through normal 
NASA funding channels. 

In general, this arrangement worked well. There was some delay at the beginning in 
establishing both the main contract and the individual subcontracts. Much of this delay could 
be attributed to the learning process and approval process on the part of both USRA and 
NASA procurement personnel. However, there were significant benefits to having the 
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funding flow through a single non-govemment organization. It allowed for more coordination 
of the activities than would have been likely had the funding been dispersed in a more 
distributed fashion. Furthermore, USRA was able to act as an agent on the part of the 
universities to obtain the many NASA approvals for items like equipment procurement. It 
was the consensus of most of the participants in the TTPP that a centralized contractual 
arrangement such as that used in the TTPP would be desirable for any continuation of rapid- 
prototyping testbedding activity. 

Deliverables vs. Guidelines 

The TTPP has resulted in many reports, ranging from technical reports from the various 
university activities through to the monthly, quarterly, interim and final reports from the 
program as a whole. However, such reports are only part of the needed deliverables from 
such a program. There needs to be provision for technology and knowledge transfer from the 
testbedding activities into the target system development. Much of this happened, but as an 
ad-hoc process rather than through a programmatic approach. In addition, the issues 
pursued in this initial phase of the program were not selected in advance, but rather were a 
consequence of the proposed activities. 

Thus, any follow-on program would be significantly enhanced through the identification 
of the critical issues prior to selection of the individual testbedding activities. The results of 
the TTPP documented elsewhere in this report can be used as input to that selection 
process. By selecting the issues to be attacked at the beginning and basing that selection in 
part on the needs and issues of the target system, the knowledge and technology transfer 
process can be incorporated into the program as an integrated element. 

Use of the results of the program would also be enhanced by having a separate activity 
actively working on the integration of requirements, definition of architecture, and 
coordination with the system developers. While there have been many results developed as 
part of the TTPP, it was not clear what the programmatic and institutional process was to 
transfer those results into requirements and system development. A systems engineering 
activity coordinating the testbedding activity with systems development, requirements 
definition, and related activities would have been most helpful as the program proceeded. 

This would have allowed the necessary multi-disciplinary and multi-organizational activities 
to be pulled together into a team attacking these critical questions. 

Lessons Learned vs. Recommendations 

The TTPP, as any set of testbedding activities, only attacked a subset of the issues and 
questions. It was targeted at those issues best addressed via a testbedding approach. 

Other activities, such as the systems engineering activity above along with a variety of 
analytical and simulation studies, are also required to pull together a set of reasonable and 
coherent recommendations and requirements for the information system of the Space Station 
era. 


Thus, a rapid-prototyping testbed activity should only be asked and expected to 
document what it did and what lessons were learned in that process. It should not be 
expected to pull together a set of requirements nor an overall system architecture. The 
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integration of the testbed results together with the other aspects would logically be done 
through a systems engineering activity working in close cooperation with a multi-disciplinary 
working group representing the testbedding activities, simulation and studies, and systems 
development. The testbed activity can be expected to validate and explore aspects of such 
an architecture. The identification of the critical issues to be investigated via testbedding is 
again an important aspect of any overall information systems activity. 

Scheduling vs. Funding Availability 

There was a much larger delay in putting in place the overall TTPP contract and the 
various subcontracts than was expected. It took approximately one year from the time that 
USRA submitted the proposal to the time that the last of the university subcontracts were 
approved. This in fact is not a particularly large delay for government procurements but was 
larger than anticipated. 

The major impact of this delay was to create uncertainty and changes in the scheduling 
of the various testbed activities. All of the university testbeds were based on ongoing 
scientific research, and it was expected that the TTPP activity would mesh with those 
activities according to a schedule beginning roughly January 1987. In fact, many of the 
universities did not receive funds until the fall of 1987, resulting in significant changes to the 
schedule of activity. Had this schedule been known at the beginning of the program, it could 
have easily been accommodated. 

Thus, the lesson learned is that, even though a rapid-prototyping testbed activity 
needs to maintain flexibility, the need to build on existing and ongoing activities demands a 
schedule that is known in advance. 

Equipment Procurement 

One of the major difficulties encountered during the program was the rationalization of 
the nature of rapid-prototyping against the NASA equipment procurement procedures. This 
resulted in a compounding of the delays already encountered in dealing with several 
equipment manufacturers. This problem was especially noticeable in the area of workstation 
procurements. 

Rapid-prototyping requires the ability to rapidly test out new technologies and 
approaches, and often requires obtaining new equipment quickly. The current NASA 
equipment procurement procedures require considerable specificity in the equipment 
descriptions needing approval. This, coupled with the rapid changes in technology, often 
meant that by the time the equipment procurement was approved, there was a new (or 
sometimes two new) generation of technology. In addition, because the universities often 
could not risk placing orders prior to receiving approval, the delays became additive. A 
procurement mechanism more suitable to a rapid-prototyping approach is needed to allow 
rapid identification and acquisition of new technologies for evaluation purposes. 
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Facilities Installed 

In addition to equipment required to support the testbedding activities, many of the 
testbeds needed other facilities. For example, many of the universities carried out 
experiments requiring use of a shared packet switched network (i.e. the NASA Science 
Internet). Others needed access to video links and planned to use NASA provided circuits. 
The scheduling and installation of such facilities turned out to cause major delays in a number 
of the testbeds. Again, like in the case of equipment, there is a need for a procedure for 
scheduling installation and use of facilities in a manner compatible with a rapid-prototyping 
testbed. This means being able to identify the need for such facilities and arrange for its 
installation and/or scheduling with minimal delay, in contrast to the typical multi-year cycle 
of requirements definition and planning that typifies major facilities, such as PSCN, 
NASCOM, and aircraft. 

Agency Commitment and Support 

Part of the solution to both the equipment and facilities issues raised above lies in an 
agency commitment and support of telescience and a rapid- prototyping testbed approach. 
With such a commitment at the highest levels, it would be possible to work with both 
procurement and facilities organizations to arrange (on a high priority flexible basis) for the 
rapid procurement of equipment and the flexible scheduling of facilities. 

One possible approach to this issue would be to have a multi-organizational review of 
the engineering plan for each testbed activity at proposal time. Such a review would involve 
all organizations expected to provide facilities in support of the proposed experiment. If the 
experiment were approved by the review body, it would carry with it the approval of and 
commitment of support to the testbed by each of the participating organizations. 

Aspirations for Field Campaigns 

A number of the testbeds, particularly those in the earth sciences area, applied 
advanced technologies and methods to campaign experiments involving multiple 
organizations and sensors. Such activities require considerable coordination, planning, and 
scheduling. The delays in funding along with delays in installation of needed facilities 
resulted in the campaign experiments not being carried out totally successfully. 

Management of any future campaign-style testbed experiments needs to pay close 
attention to the management of expectations. Funding needs to be put in place before the 
field campaigns are planned, and careful planning needs to be carried out of exactly who is 
involved, their specific activities, and the coordinated schedule. Attention must be paid to 
the fact that the larger the activity and number of participating organizations involved, the 
more difficult such planning and scheduling will become. Therefore, there is a trade-off 
between the desire to carry out campaign experiments representative of the large scale 
activities anticipated in the space station era and the need to have small, manageable 
experiments for a rapid- prototyping approach. 
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Flexibility in Context of Project Structure 

A rapid-prototyping testbed inherently requires flexibility. As the testbed leams the 
positives and negatives of particular technical and procedural approaches, it needs to be able 
to modify its approach, equipment, and procedures. Nevertheless, the overall testbedding 
program needs to identify the critical issues to be addressed, each testbed needs to be 
specific about what it will be contributing to the project goals, and each testbed has to work 
with the particular science activity to assure that the science goals are achieved. This 
means that a balance must be maintained at all times between the needed flexibility, the 
overall project structure, and the objectives of the cooperating science activities. 

Prototy ping Time Scale 

All of the university testbeds in the TTPP were based on the principle of augmentation 
of existing scientific research activities. In some cases, this meant that the small 
modifications to incorporate new technologies and approaches yielded large gains in 
understanding and productivity. These often yielded payoff in rapid time. 

However, in some cases, the incorporation of advanced technologies required more lead 
time, as new facilities (e.g. PSCN circuits) or new equipment (e.g. workstations) were 
installed or procured. In these cases, while there was tremendous productivity increases 
made possible through the use of the new technology, and the scientific program would not 
have been able to explore the new approaches without the TTPP activity, delays were 
incurred as the new facilities were installed or procured. 

The lesson learned from this is that it takes time to install the needed machinery to 
carry out a rapid-prototyping activity. “Rapid” requires being able to leverage off of existing 
facilities and equipment. Thus, one of the major contributions of the TTPP has been one of 
investment; installing the required facilities and equipment to allow rapid-prototyping of new 
techniques to take place more rapidly in the future. Any future activity must pay close 
attention to maintaining an infrastructure to carry out rapid- prototyping. This includes 
people and coordination mechanisms as well as equipment and facilities. 

University Staff Commitment 

The TTPP activity was a one year program. Normal university practices in hiring, 
funding, and research demands that research programs be long-term activities (a minimum of 
three years). Such a commitment is required to permit the training, use, and commitment of 
graduate students and staff as well as faculty researchers. In fact, the understanding of the 
participants in the TTPP was that the TTPP was to be the initial phase of a multi-year 
program with the initial year focussed on validation of the approach and subsequent funding 
dependent only on the success of the first year. Without that understanding, it is not clear 
whether the universities would have been able to participate. 
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Coordination, Integration, and Information Flow 

The TTPP involved a large number of organizations and people, including universities, 
NASA Centers, NASA HQ, and various industrial contractors and cutting across scientific 
research, technology, space station, and other activities including networking and 
communications. Validating and exploring the approaches for conducting such a program was 
one of the major objectives of the TTPP. 

A number of lessons were learned concerning the coordination and information flow in 
such a dispersed and flexible program. These are best described by noting that there was a 
need to promote information flow between: 

• the universities themselves, 

• the universities and USRA/RIACS, 

• the TTPP and NASA HQ, and 

• the TTPP and other interested parties (e.g. space station contractors). 

A variety of mechanisms were used to support this information flow, including: 

• electronic mail, 

• working groups with associated electronic mailing lists, 

• monthly and quarterly reports with electronic distribution, 

• program meetings, and 

• briefings. 

Electronic mail was used extensively throughout the program starting with the 
development of the proposal and continuing to the preparation of this final report and beyond. 
It was used for a multitude of purposes, including: 

• bilateral communications (e.g. specific exchanges between universities, 
between universities and others such as program management, arid to answer 
queries from interested parties) 

• group activities (e.g. preparation of group reports and coordination of campaign 
experiments), and 

• dissemination of information (e.g. distribution of monthly reports and requests 
for programmatic inputs from RIACS to the universities) 

Electronic mail was absolutely essential to the conduct' of the program. It would have 
been virtually impossible to have carried out the program as a coordinated and integrated 
activity without it. Even so, there were several problems encountered. One complaint 
voiced by a number of participants was the length of mail “header” information. Upon 
investigation, this turned out to be more due to the forwarding of mail between different mail 
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systems (mostly between NASAmail and Internet mail). Because of the nature of the 
typical NASAmail interface, this was particularly onerous on the NASAmail users. Internet 
mail users typically read their mail on an advanced workstation and therefore have more 
flexibility and power to deal with long messages. 

One issue that surfaced was the large amount of electronic mail and the need to 
establish guidelines on its use. This was noticed in two ways. First, many messages were 
sent to larger groups than necessary. For example, a reply to a query sent to a group might 
be sent to the whole group when it was only necessary to send it to the original source of the 
query. Second, a need was identified for handling the large amounts of mail, sorting it, 
prioritizing it, and associating it with other messages of similar subject matter. 

The large amount of mail also taxed the local mail systems at times. Towards the end 
of the program, an attempt was made to use bulletin board and public file transfer capabilities 
more. Long reports and messages were put on the bulletin board or publicly accessible file 
system, and only a notice of the availability of the report was sent via electronic mail. This 
appears to have some promise. However, an investigation will be needed as to whether 
affiliated people for whom the reports were peripheral to their major activities would be less 
likely to read the reports if they had to take the additional step of retrieving it rather than 
having it as a part of their main electronic mail stream. 

Another problem encountered was related to the maintenance of the many electronic 
mailing lists. Lists were maintained for each of the participating scientific disciplines as well 
as general programmatic purposes. For example, a list was maintained (called TTPP- 
NEWS) for the purpose of dissemination of program information (such as the monthly 
reports) to all interested parties. By the conclusion of the program, this list had about 400 
people on it. Maintaining this list with accurate addresses was a non-trivial issue and 
required a fair amount of time by the administrative support personnel at RIACS. 

Nevertheless, feedback from those receiving the reports (particularly those not involved in 
TTPP per se such as Space Station government personnel) was positive and attested to the 
value of keeping them informed as to the progress and results in the program on an ongoing 
basis. Any future activity should make sure that appropriate facilities are provided to 
maintain such mailing lists. (RIACS used a relatively standard database program to 
accomplish this and it was satisfactory.) 

In order to assure that the program would generate useful results, it was organized 
according to scientific discipline, with groups associated with earth systems sciences, 
astronomy and astrophysics, life sciences, and microgravity sciences. Each group had a 
leader that was responsible for working with the participants in that discipline to coordinate 
and integrate their activities and results. This approach worked relatively well. It allowed 
for focus on specific issues of concern to each discipline in a flexible manner. It is critical that 
these working groups be well coordinated with the NASA management structure inside 
OSSA. 

To make sure the results of the TTPP were well documented and disseminated, 
monthly and quarterly reports were generated in addition to the normal technical reports of 
the individual activities. The monthly reports were intended to be informal brief reports to 
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keep everyone informed of each others activities, thereby helping to coordinate the program. 
Unfortunately, the well known phenomenon that it is easier to write a long report than a 
short one took hold. The monthly reports became fairly detailed and lengthy, despite the 
original guidance of requesting that the inputs be just a few paragraphs for each university, 
focussing on just highlights. A similar difficulty occurred with the quarterly reports, which 
were intended to simply be status reports. 

This had a beneficial side, though. While the TTPP subcontractors felt that the number 
and length of reports was excessive, the other participants and recipients of the reports 
indicated that they found both the monthly and quarterly reports quite helpful in tracking the 
progress of the program and staying abreast of developments. 

On the whole, it was the consensus of the group that NASA’s purposes would have 
been better served through shorter reports, but the monthly reports were helpful and useful. 
The USRA Program Manager, in retrospect, should have emphasized summaries in the 
monthly and quarterly reports with appropriate pointers to the detailed reports. The 
summaries could have been generated by the USRA Program Manager or he/she could have 
provided stronger guidance and direction to the preparation of the report sections by the 
subcontractors (or both). 

Finally, several meetings were held throughout the life of the program, beginning with 
the initial proposal formulation and continuing through the writing of the final report. These 
meetings were all deemed as extremely useful and productive, whether they were working 
meetings or presentation and demonstration oriented. The latter were particularly useful in 
supporting information transfer to those outside the immediate TTPP participants. Attended 
by personnel from NASA HQ, space station at all levels, and a number of space station 
contractors, the larger meetings (attended by approximately 100 people) provided an 
opportunity to share information and exchange views on a variety of subjects. It is critical 
that such meetings continue to provide a forum for exchange between the various science, 
research, and development communities. 
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Bennett, Elliot, HOLOP: A Case Study of Advanced User-interface Design for Interactive 
Control of Space Experiments, DFVLR IB 333 - 88/5, 24 pp., DFVLR, Institute for 
Space Simulation, Cologne, West Germany, June 1988. 

This paper details advanced concepts in user-interface design implemented in the computer program 
HOLOP Ops. HOLOP Ops was designed to provide a simple, easy, and fast user-interface for remote, 
interactive control the HOLOP facility aboard the D2 Spacelab mission. Such a user-interface is 
achieved by implementing full graphics capabilities (including pictures, icons, graphs, and mouse/cursor 
control) as well as full text displays and control in a transparent, integrated environment for 
experiment observation and control. The advantages and capabilities of this program’s user- interface 
are described and analyzed for their ability to enhance space based science productivity in the Space 
Station era. 

Bienz, Richard A. and Larry C. Schooley, “ A Survey of Computer Networks,” Technical 
Report TSL-001/87, 85 pp., Electrical and Computer Engineering Department, 
University of Arizona, Tucson, AZ, February 1987. 

A summary of existing wide-area computer networks and their attributes and evaluation of their 
possible use in the University of Arizona TTPP testbeds. 

Bienz, Richard A., and Jerry J. Hunter, “Communication Software Design for Telescience 
Demonstrations,” Technical Report TSL-019/88, Electrical and Computer Engineering 
Department, University of Arizona, Tucson, AZ, December 1988. 

Cellier, Francois , Teleoperation of the Thaw Telescope at the Allegheny Observatory: A 

Case Study, Technical Report TSL-004/87, 56 pp., Electrical and Computer Engineering 
Department, University of Arizona, Tucson, AZ, December 1987. 

Primary purpose of this document is to define the intermediary language to be used for computer-to- 
computer communication between the local controlling computer at Allegheny Observatory and the 
remote commanding computer which will be located at the University of Arizona. Overview of plans 
leading to teleoperation the Thaw Telescope at Allegheny Observatory is also discussed as well as 
control loops, sensors, safeguard error messages. 

Chakrabarti, Supriya, Carl A. Dobson, and J. G. Jemigan, “Telescience at the U. C. Berkeley 
Space Science Laboratory,” Bulletin of the American Astronomical Society, vol. 19, p. 
744, Space Sciences Laboratory, U.C. Berkeley, June 1987. 

The University of California, Berkeley is a member of a University consortium developing 
methodologies for remote design, development and operation of space instrumentations, collectively 
termed telescience. We will discuss our efforts in extending an existing local software control 
system to allow the development and sharing of software between remote sites. We are developing a 
methodology for the remote operation of instrumentations utilizing networks such as the ARPANET. 

These techniques have already been demonstrated over a local Ethernet These two areas of 
investigations address the teledesign and teleoperation components of telescience. 
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Chakrabarti, Supriya, Carl A. Dobson, George C. Kaplan, Herman L. Marshall, Michael 
Lampton, Roger F. Malina, Stuart Bowyer, and Jeff Star, “Astronomical Data 
Analysis from Remote Sites,” Astronomy from Large Databases, Scientific Objectives 
and Methodological Approaches, ESA Conference and Workshop Proceedings, vol. 28, 
p. 295, Space Sciences Laboratory, UC Berkeley & Remote Sensing Research Unit, 
UC Santa Barbara (J. Star), Berkeley, C A, January (1988c). Also available in Space 
Astrophysics Group Contribution Number 329. 

Given the progress in the communication technology, it is expected that during the space station era the 
mode of instrument operation and data analysis will be dramatically different. A consortium of 
several universities and NASA centers are evaluating various aspects of design and operation of 
scientific instruments and data analysis over various computer networks from a remote site. Such a 
scheme has officially been termed telesrience. We will report on the development of methodologies 
for teledesign, teleoperation and teleanalysis and the verification of these concepts using the Extreme 
Ultraviolet Explorer (EUVE), a satellite payload scheduled for launch in 1991. The EUVE telescopes 
will be operated remotely from the EUVE Science Operation Center (SOC) located at the University 
of California, Berkeley. Guest observers will remotely access the EUVE spectrometer data base 
located at the SOC. Distributed data processing is an integral part telescience. We will describe our 
experience with the Browse system, currently being developed at the University of California at Santa 
Barbara through a grant from NASA for remote sensing applications. We will discuss the suitability 
for its adoption for astronomy applications. Browse allows the examination of a subset of the data to 
determine if the data set ments further investigation. The examination can be as simple as looking for 
a specific data element based on its location, date of observation, quality indicator, spectral coverage 
etc. It also allows the viewing of data in various modes depending upon the available resources at the 
user’s end (e.g., graphics terminal vs. dumb terminal), level of data compression applied, required 
display format etc. and its transmission over a network to a local graphics display station. 

Chakrabarti, Supriya, William T. Marchant, George C. Kaplan, Carl A. Dobson, J. Garrett 
Jemigan, Michael L. Lampton, and Roger L. Malina, “Telescience at the University of 
California, Berkeley,” Acta Astronautica, in press, (1988a). Also available in Space 
Astrophysics Group Contribution Number 356. 

The University of California at Berkeley (UCB) is a member of a university consortium involved in 
telescience testbed activities under the sponsorship of NASA. Our Telescience Testbed Project consists 
of three experiments using flight hardware being developed for the Extreme Ultraviolet Explorer 
project at UCB’s Space Sciences Laboratory. The first one is a teleoperation experiment investigating 
remote instrument control using a computer network such as the Internet. The second experiment is an 
effort to develop a system for operation of a network of remote workstations allowing coordinated 
software development, evaluation, and use by widely dispersed groups. The final experiment concerns 
simulation as a method to facilitate the concurrent development of instrument hardware and support 
software. We describe our progress in these areas. 

Chakrabarti, Supriya, William T. Marchant, Carl A. Dobson, George C. Kaplan, Michael L. 
Lampton, and Roger L. Malina, “Remote Command and Telemetry Handling for a 
Spaceflight Instrument,” Proceedings ofIECON’88: Control and Simulation, Singapore , 
v m, pp. 325, Space Sciences Laboratory, UC Berkeley, Berkeley, CA, (1988b). Also 
available in Space Astrophysics Group Contribution Number 365. 

The Space Sciences Laboratory at the University of California, Berkeley, is a member of a university 
consortium involved in telescience testbed activities under the sponsorship of NASA. As part of our 
activities, we have developed methodologies for remotely commanding a space-based instrument and 
receiving telemetered data. Two experiments were conducted to interact remotely with a flight- 
destined instrument In the first experiment we sent commands using the Bay Area Regional Research 
network from a computer at Stanford University to an instrument connected to a workstation located 
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at the University of California, Berkeley. In the second experiment we used the Internet to conduct 
the same experiment from the University of Colorado, Boulder. In addition to telemetry, low-rate 
video images of the instrument were transmitted over the same network to provide visual feedback. 

Although further testing is necessary, our limited experience indicates that it will be possible to 
interact with a space-based instrument from an experimenter’s desk. 

Chakrabarti, Supriya, D. Cotton, M. Lampton, O. Siegmund, R. Link, and G. R. Gladstone, 
“Remote Sensing of Atmospheric Oxygen from a Sounding Rocket,’’ Acta 
Astronautica, in press, (1988d). 

Davis, R., J. Faber, E. Hansen, A. Jouchoux, and G.H. Ludwig, Telescience Testbed Program 
Results, LASP Report 89-1, University of Colorado, Boulder, CO, January 1989. 

Forgy, C. L., “Rete: A Fast Algorithm for the Many Pattem/Many Object Pattern Match 
Problem,’’ Artificial Intelligence 19, 1982, pp. 17-37. 

Gallagher, Maria L., Telescience Testbed Kickoff Meeting Minutes, RIACS TR 87.25, 26 
pp., RIACS/USRA, Moffett Field, CA, September 1987. 

The kickoff meeting for the Telescience Testbed Pilot Program was held on July 30-31, 1987 at NASA 
Ames Research Center. These are the minutes of that meeting. 

Gallagher, Maria L., Telescience Testbed Pilot Program Meeting II Minutes, RIACS M88.1, 
RIACS/USRA, Moffett Field, CA, March 1988. 

The TTPP II meeting was held on March 7-9, 1988 in Boulder, Colorado. These are the minutes of 
that meeting 

Gallagher, Maria L. and Barry M. Leiner, Telescience Testbed Pilot Program First Quarterly 
Report, RIACS TR 87.26, 35 pp., RIACS/USRA, Moffett Field, CA, September 1987. 

The Telescience Testbed Pilot Program participants are required to issue reports to NASA 
Headquarters on a quarterly basis. This is the first quarterly report, covering the period April 28, 

1987 through August 31, 1987. 

Gallagher, Maria L. and Barry M. Leiner, Telescience Testbed Pilot Program Second 
Quarterly Report, RIACS TR 87.31, 57 pp., RIACS/USRA, Moffett Field, CA, 

December 1987. 

The Telescience Testbed Pilot Program is an innovative activity involving fifteen universities in user- 
oriented rapid-prototyping testbeds to develop the requirements and technologies appropriate to the 
information system of the Space Station era. The Telescience Testbed Pilot Program is required to 
issue progress reports to NASA Headquarters on a quarterly basis. This is the second quarterly 
report, covering the period September 1, 1987 through November 30, 1987. 

Gallagher, Maria L. and Barry M. Leiner, Telescience Testbed Pilot Program Third Quarterly 
Report, RIACS TR 88.8, 77 pp., RIACS/USRA, Moffett Field, CA, March 1988. 

The Telescience Testbed Pilot Program is required to issue progress reports to NASA Headquarters on 
a quarterly basis. This is the third quarterly report, covering the period December 1, 1987 through 
February 29, 1988. 

Gallagher, Maria L. and Barry M. Leiner, Telescience Testbed Pilot Program Fourth 

Quarterly Report, RIACS M88.4, 69 pp., RIACS/USRA, Moffett Field, CA, June 1988. 

The Telescience Testbed Pilot Program is required to issue progress reports to NASA Headquarters on a 
quarterly basis. This is the fourth quarterly report, covering the period March 1, 1988 through 
August 31, 1988. 
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Gallagher, Maria L. and Barry M. Leiner, Telescience Testbed Pilot Program Fifth Quarterly 
Report, RIACS M88.5, 76 pp., RIACS/USRA, Moffett Field, CA, September 1988.. 

The Telescience Testbed Pilot Program is required to issue progress reports to NASA Headquarters on 
a quarterly basis. This is the fifth quarterly report, covering the period September 1, 1988 through 
December 31, 1988. 

Hack, B., Man to Machine, Machine to Machine and Machine to Instrument Interfaces for 

Teleoperation of a Fluid Handling Laboratory, Technical Report TSL-014/88, Electrical 
and Computer Engineering Department, University of Arizona, Tucson, A Z, June 1988. 
The purpose of this thesis is the design and description of the software necessary for teleoperation of a 
remotely operated fluid handling laboratory. It does not include the implementation of this software. 

The laboratory for which it is designed is currently being developed at the University of Arizona, and 
is intended to be a small scale model of the fluid handling laboratory which will be aboard Space 
Station. The designed software includes a man/machine interface, a machine/machine interface, and a 
machine/instrument interface. The man/machine interface is graphical in nature, menu driven, and 
consists of high level commands which are independent of the devices in the laboratory. The 
machine/machine interface is also device independent. It consists if intermediary commands and maps 
the commands of the man/machine interface to low level, device dependent, commands and programs of 
the machine/instrument interface. Although the software is primarily designed for the model fluid 
handling laboratory, the needs and requirements of the operation of a similar laboratory aboard Space 
Station have been considered. 

Haines, Richard F., Human Performance Validation Procedures Applicable to Telescience 
Activities, RIACS TR (in final review), January 1989. 

Johnson, Vicki and John Bosley, “A Shared-World Conceptual Model for Integrating Space 
Station Life Sciences Telescience Operations,” Proc. 1988 Goddard Conference on 
Space Applications of Artificial Intelligence, Goddard Space Flight Center, May 1988. 

Jouchoux, A., Ada Compiler Choice, LASP Report, University of Colorado, Boulder, Co, 
January 1988. 

Kallemeyn, P.H., B. Knapp, and G.H. Ludwig, User's Manual - Science Data Base Access 
Program for the Solar Mesosphere Explorer, LASP Report 89-3, University of 
Colorado, Boulder, Co, April 1989. 

Kaplan, George C., “EUVE Contributions to Telescience,” EUVE Technical Bulletin, no. 4, 
p. 2, Space Sciences Laboratory, UC Berkeley, Berkeley, CA, September 1987. 

Brief Overview of UC Berkeley’s telescience experiments for the TTPP. 

Koch, David, Terry Herter, John Stauffer, and Erick Young, Telescience Applied to the Space 
Infrared Telescope Facility, 8 pp., Smithsonian Astrophysical Observatory (Koch); 
Department of Astronomy, Cornell University (Herter); NASA/Ames Research Center 
(Stauffer); Steward Observatory, University of Arizona (Young), September 1987. 

In the future, the approach to the conduct of scientific space missions will be substantially different 
from the approach that has been used in the past. A more distributed approach will be taken with the 
scientists conducting operations and analysis, remotely from their home institutions, making major use 
of standardized software and compatible hardware. Key to this approach have been the rapid adoption 
of the use of local and wide area networks, the use of standardized software tools and the plethora of 
powerful workstations. These developments will be applied to the Space Infrared Telescope Facility 
project in the space station era. A number of telescience testbed activities are being undertaken to 
develop experience and to determine the applicability of telescience methods. 
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Leiner, Barry M., Telescience Testbed Pilot Program , RIACS TR 87.12, 42 pp., 
RIACS/USRA, Moffett Field, CA, May 1987. 

The Telescience Testbed Pilot Program is an innovative activity to address a number of critical issues in 
the conduct of science in the Space Station era. Several scientific experiments using advanced 
information processing and communications technologies will be carried out and the results evaluated 
to determine the requirements and their priorities. This will provide quantitative evidence as to the 
relative importance of different functions in the SSIS and their required performance. Furthermore, it 
will allow a set of scientific users to gain experience with advanced technologies and their application 
to science. This report is based on the proposal from USRA to NASA for the establishment of the 
Telescience Testbed Pilot Program. It describes the motivation for the program, the structure of the 
effort, and several strawman scientific experiments that constitute the heart of the activity. 

Leiner, Barry M. and James R. Weiss, Telescience Testbedding: An Implementation 
Approach , RIACS TR 88.2, 9 pp., RIACS/USRA (Leiner) & NASA/HQ (Weiss), 
Moffett Field, CA, February 1988. 

Telescience is the term used to describe a concept being developed by NASA’s Office of Space Science 
and Applications (OSSA) under the Science and Applications Information System (SAIS) Program. 

This concept focuses on the development of an ability for all OSSA users to be remotely interactive 
with all provided information system services for the Space Station era. This concept includes access to 
services provided by both flight and ground components of the system and emphasizes the 
accommodation of users from their home institutions. Key to the development of the Telescience 
capability is an implementation approach called rapid-prototype testbedding. This testbedding is used 
to validate the concept and test the applicability of emerging technologies and operational 
methodologies. Testbedding will be used to first determine the feasibility of an idea and the 
applicability to real science usage. Once a concept is deemed viable, it will be integrated into the 
operational system for real time support It is believed that this approach will greatly decrease the 
expense of implementing the eventual system and will enhance the resultant capabilities of the 
delivered systems. 

Leiner, Barry M., Telescience Testbed Pilot Program Interim Report, RIACS TR 88.6, 16 pp., 
RIACS/USRA, Moffett Field, CA, February 1988. 

The Universities Space Research Association (USRA), under sponsorship from the NASA Office of 
Space Science and Applications, is conducting a Telescience Testbed Pilot Program. Fifteen 
universities, under subcontract to USRA, are conducting a variety of scientific experiments using 
advanced technology to determine the requirements and evaluate trade-offs for the information system 
of the space station era. This report represents an interim set of recommendations based on the 
experiences of the first six months of the pilot program. 

Lew, A. K., Astrometric Telescope Simulator for the Design and Development of Telescope 
Teleoperation, Technical Report TSL-016/88, Electrical and Computer Engineering 
Department, University of Arizona, Tucson, AZ, September 1988. 

Lichtenberg, Byron K., “Concepts for Crew Experiment Interaction-Future Space Flights: 
Workstation Design and Requirements,” p. 3, Payload Systems, Inc., June 1988. 
Submitted to the International Conference on Environmental Systems to be held July 
1988. 

Current space lab and space shuttle workstations are inadequate for the next generation of space 
experimentation. The capability of the current experiment computers is severely limited, the 
maximum sample rate that can be acquired and processed for on board display is 10 samples per second, 
and the displays have a maximum of 750 woof storage associated with them. Second, the ability to 
modify experiment operations real time is nonexistent unless it was programmed in approximately 18 
months before flight. The appearance of new generations of computers will alleviate these problems, 
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but acceptance by the space engineering community is still Limited. This paper will discuss the 
concepts and requirements for future workstations and capabilities that should be inherent in the next 
generation of space craft. 

Marchant, Will, Carl A. Dobson, Supriya Chakrabarti, and Roger F. Malina, 

“Telescience - Concepts and Contributions to the Extreme Ultraviolet Explorer 
Mission,” SPIE Proceedings, vol. 851, p. 173, Astronomy Dept. & Space Sciences 
Laboratory, UC Berkeley, Berkeley, CA, November 1987. Also available in Space 
Astrophysics Group Contribution Number 315. 

A goal of the telescience concept is to allow scientists to use remotely located instruments as they 
would in their laboratory. Another goal is to increase reliability and scientific return of these 
instruments. In this paper we discuss the role of transparent software tools in development, 
integration, and post-launch environments to achieve hands on access to the instrument. The use of 
transparent tools helps us to reduce the parallel development of capability and to assure that valuable 
pre-launch experience is not lost in the operations phase. We also discuss the use of simulation as a 
rapid prototyping technique. Rapid prototyping provides a cost-effective means of using an iterative 
approach to instrument design. By allowing inexpensive production of testbeds, scientists can quickly 
tune the instrument to produce the desired scientific data. Using portions of the Extreme Ultraviolet 
Explorer (EUVE) system, we examine some of the results of preliminary tests in the use of 
simulation and transparent tools. Additionally, we discuss our efforts to upgrade our software 
"EUVE electronics" simulator to emulate a full instrument, and give the pros and cons of the 
simulation facilities we have developed. 

Pan, Ya-Dung, Teleoperation of Mechanical Manipulators Aboard the U.S. Space Station, 
Technical Report TSL-002/87, 74 pp.. Electrical and Computer Engineering 
Department, University of Arizona, Tucson, AZ, December 1987. 

This study presents a new analytical controller design strategy for the teleoperation of mechanical 
manipulators aboard the U.S. space station. This controller design strategy emphasizes on the stability 
of a closed-loop control system involving time delay. Simplified dynamic equations of the Stanford 
arm are considered as the manipulator model. A local linearizing and decoupling control algorithm is 
applied to linearize and decouple the dynamic equations. Once the linear form of the manipulator is 
obtained, a model prediction control loop is constructed and implemented as a digital controller to 
provide the predictive states information, and a particular model reduction method is applied to yield a 
reduced-order digital controller. This reduced- order digital controller is a highly self-tuned 
controller which can control the closed-loop system with time delay by following a specified 
performance. 

Pan, Ya-Dung and Alfie K. Lew, Teleoperations Software for Remote Fluid Handling, 
Technical Report TSL-020/88, Electrical and Computing Engineering Department, 
University of Arizona, Tucson, AZ, December 1988. 

Pennisi, Liz, “Computers on Long-Distance Research,” LQP, p. 8, December 7, 1987. 

Magazine article on the use of computers on long-distant research at the University of Arizona. 

Raize, Efraim, Computer Interface for Electrophoresis Apparatus, Technical Report TSL- 
01 1/88, 28 pp., Electrical and Computer Engineering Department, University of 
Arizona, Tucson, AZ, May 1988. The author is a visiting scholar at the University of 
Arizona. 

This report summarizes the considerations required for an adequate interface, lists the electronics 
design and shows the drawings and procedures for operation and maintenance of an Electrophoresis 
machine in an automated laboratory. 
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Raize, Efraim, Syringe Driver Assembly for Automatic Fluid Handling Laboratory , 
Technical Report TSL-012/88, 17 pp., Electrical and Computer Engineering 
Department, University of Arizona, Tucson, AZ, May 1988. The author is a visiting 
scholar at the University of Arizona. 

This report describes the design and implementation of a driver assembly for an automated fluid 
handling laboratory. 

Rasmussen, Daryl, Arshad Midan, and John Bosley, “Telescience Testbedding for Life 

Science Mission on the Space Station,” AJAA Aerospace Science Meeting, Reno, NV, 
January 1988. 

Rasmussen, Daryl, Vicki Johnson, and Arshad Mian, “Telescience Concept for Habitat 

Monitoring and Control,” 18th Intersociety Conference on Environmental Systems, San 
Francisco, CA, July 1988. 

Schmerling, Erwin, “The Interaction of Users with Instruments and Databases in Space,” 
Information Systems Newsletter , pp. 12-18, NASA Headquarters, January 1988. 

This article discusses the Telescience Testbed Pilot Program’s objectives, planned contributions and 
defines the term Telescience. 

Schmerling, Erwin, “Telescience in the Space Station Era,” EASCON, pp. 1-6, NASA 
Headquarters, September 1988. 

After over a quarter of a century of experience in space, and the rapid development of Information 
Systems capabilities, there is a naturally growing demand for the development of systems where, to an 
increasing extent, participants can access their fellow scientists and the appropriate NASA service 
before flight, during flight and after flight, preferably from their home institutions and through the 
same equipment. This concept has become known as Telescience, and sporadic examples of its 
implementation may be found in earlier programs. 

Schooley, Larry C. and Francois Cellier, Telescience Testbed Pilot Program Quarterly 
Report, Technical Report TSL-003/87, 16 pp., Electrical and Computer Engineering 
Department, University of Arizona, Tucson, AZ, December 1987. 

First quarterly report for the University of Arizona’s Telescience Testbed Pilot Program. 

Schooley, Larry C., Richard A. Bienz, and Francois Cellier, Basic Research in Telescience 
Testbed Program Final Report: NASA Grant NAGW-1073, Technical Report TSL- 
005/88, Electrical and Computer Engineering Department, University of Arizona, 
Tucson, AZ, January 1988. 

Final report for NASA grant NAGW-1073. 

Schooley, Larry C., Don G. Schultz, and Francois Cellier, University of Arizona 

Presentation, Second Telescience Testbed Pilot Program Meeting, Technical Report 
TSL-007/88, 50 pp., Electrical and Computer Engineering, University if Arizona, 
Tucson, AZ, March 1988. 

The set of transparencies presented by the University of Arizona at the second TTPP meeting held in 
Boulder, CO on March 7-9, 1988. 

Schooley, Larry C. and Francois Cellier, Telescience Testbed Pilot Program Quarterly 
Report For Winter 1987-88, Technical Report TSL-008/88, 15 pp., Electrical and 
Computer Engineering Department, University of Arizona, Tucson, AZ, March 1988. 
Second quarterly report for the University of Arizona’s Telescience Testbed Pilot Program. 
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Schooley, Larry C. and Francois Cellier, Telescience Testbed Pilot Program Quarterly 

Report for Spring 1988, Technical Report TSL-013/88, 10 pp.. Electrical and Computer 
Engineering Department, University of Arizona, Tucson, AZ, June 1988. 

This is the third quarterly report for the astrometric telescope, remote fluid handling, and technology 
development projects at the University of Arizona. It does not include the UA involvement in the 
SIRTF project. 

Schooley, Larry C. and Francois Cellier, Telescience Testbed Pilot Program Quarterly 
Report For Summer 1988, Technical Report TSL-018/88, Electrical and Computer 
Engineering Department, University of Arizona, Tucson, AZ, September 1988. 

Summer 1988 quarterly report for the University of Arizona’s Telescience Testbed Pilot Program. 

Schooley, Larry C. and Francois Cellier, Telescience Testbed Pilot Program Final Report, 
Technical Report TSL-021/88, Electrical and Computer Engineering Department, 
University of Arizona, Tucson, AZ, December 1988. 

Final report for the University of Arizona’s Telescience Testbed Pilot Program. 

Schooley, Larry C., and Francois E. Cellier, Teleoperation of a Simulated Astrometric 
Telescope, Technical Report TSL-022/88 (videotape), Electrical and Computer 
Engineering Department, University of Arizona, Tucson, AZ, December 1988. 

Schooley, Larry C., and Francois E. Cellier, Don G. Schultz, Teleoperation of a Fluid 
Handling Laboratory, Technical Report TSL-023/89 (videotape). Electrical and 
Computer Engineering Department, University of Arizona, Tucson, AZ, January 1989. 

Schultz, Don G. and R. Fardid, An Automated Remote Fluid Handling System, Technical 
Report TSL-0 15/88 (videotape), Systems and Industrial Engineering Department, 
University of Arizona, Tucson, AZ, July 1988 

Secord, Terry, Life Sciences Facility Control and Telescience Systems, Technical Report 
MDCH3658, McDonnell Douglas, Huntington Beach, CA, July 1988. 

Starks, Scott, David Elizandro, Barry M. Leiner, and Michael Wiskerchen, “Computer 
Networks for Remote Laboratories in Physics and Engineering,” 1988 Annual 
Conference of the American Society for Engineering Education, June 1988, (also 
available as RIACS TR 88.13, 7 pp., April 1988). 

As we embark on a new era in engineering education, we must exploit technological advances which 
offer opportunities for improving the educational process. One area of technology which offers 
opportunities for enhancing the manner in which research is conducted and ultimately affects scientific 
and engineering education is computer networks. As computer hardware has become less expensive, 
more numerous and more capable, individuals and organizations have developed a keen interest in 
connecting them together in order to form networks. This in turn has had an impact on the manner in 
which laboratory research is conducted. This paper addresses a relatively new approach to scientific 
research, telescience, which is the conduct of scientific operations in locations remote from the site of 
central experimental activity. A testbed based on the concepts of telescience is being developed to 
ultimately enable scientific researchers on earth to conduct experiments onboard the Space Station. 

This system along with background materials are discussed in this paper. 
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This paper describes the structure and methodology of the rapid prototyping efforts and reports the 
results for the first eleven months of the 15 university telescience testbed program. In addition, the 
multi-media networking capabilities between the NASA Centers involved in space station design and 
operations, and the universities are discussed in teims of overall requirements for telecommunications 
between space station testbed/simulation facilities and the telescience testbed effort. 

Young, Larry A. and Barry M. Leiner, “Telescience,” AIAA/NASA First International 
Symposium on Space Automation and Robotics, November 1988, (also available as 
RIACS TR 88.28, 9 pp., (MIT) Young, (RIACS) Leiner, October 1988). 

Telescience is the approach and collection of tools that enable productive scientific activity to be 
carried out using remote resources. By using interactive high-performance telecommunication links 
between space-based laboratories and facilities, on-orbit crew, and geographically dispersed ground- 
based investigator groups, facilities such as Space Station become an accessible and integral part of the 
research environment. In this paper, we describe an innovative program of rapid prototyping testbeds 
aimed at evaluating and validating telescience modes of operation and the technologies to support them. 
Particular attention is given to three testbeds evaluating remote instrumentation monitoring and 
control, expert systems in support of the interaction between the principal investigator and the 
astronaut, and telerobotics in support of fluid handling. In all of the testbeds, the application of these 
new technologies have been shown to improve scientific productivity'. 
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Appendix C 
Statement of Work 

Attachment J-l 

Telescience Testbed Pilot Program 
Procurement Request 10-39111 

SECTION C - Statement of Work 

1. Background 

NASA’s Office of Space Science and Applications (OSSA) recognizes the need for 
scientists to be able to conduct experiments in conjunction with the Space Station Program 
and perform correlative data analysis from their home institutions — the telescience 
concept. In order to explore the needed application of modem Information System technology 
to enable telescience, the OSSA is creating a pilot Telescience Testbed Program. This first 
phase of this Program will identify the prerequisite high-level requirements for the design of 
the OSSA and Space Station Information and Instrument Control Systems, assure that 
telescience capabilities can be built into the initial design of Space Station Information and 
Instrument Control Systems, and establish a continuing review mechanism for the design 
and implementation of the capabilities needed to accommodate the needs of Telescience in a 
manner consistent with the desires of the OSSA user community. 

2. Scope 

This contract represents the first phase of the Telescience Testbed Program. The 
Contractor will subcontract to, manage and integrate 6-10 teams to perform testbed 
experiments, provide technical support, and issue a final report and program plan for a 
continuing telescience development program. The first phase will establish proof of concept 
and a specific set of system prerequisites to be integrated into Space Station design and the 
design of future OSSA Information Systems. 

3. Description of Effort 

The Contractor shall support the Science and Applications Information System (SAIS) 
Program Manager and Program Scientist in overseeing and integrating the overall 
interdisciplinary telescience testbed pilot program. The Contractor shall issue subcontracts 
to 6-10 teams derived from institutions such as those represented on the Task Force on the 
Scientific Use of Space Station (TFSUSS). These teams will develop and test system 
concepts, using existing equipment and prototypes to investigate real science problems. The 
Contractor shall closely coordinate the work of the teams, share information among them, 
provide expertise in state-of-the-art technologies relevant to the work, coordinate the 
teams’ work with other NASA offices and field centers, and write a Program Plan for the 
continuation of the telescience development program in the final report. 
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In performance of this contract, the Contractor shall report to the SAIS Program 
Manager and Program Scientist and work in close cooperation with the OSSA discipline 
divisions, the Office of Space Station (OSS) and all the Universities and NASA centers 
active and interested in the telescience testbed program. 

a. The contractor will receive from NASA at the time of award, a candidate list of 
testbed experiments and selection criteria which is consistent with the objectives of the 
Telescience Testbed Program. The contractor will utilize this information as a core in 
soliciting additional testbed experiment ideas from the scientific community, as well as in 
developing an approach which will ensure optimum participation in the Program and 
accomplishment of its objectives. Parallel to this effort, the Contractor shall form, with the . 
approval of the SAIS Program Manager and Program Scientist, a Telescience Testbed 
Working Group, consisting of representatives from Universities and NASA organizations, to 
participate in the evaluation of proposals and the coordination of the resulting individual 
experiments and the overall activity. 

b. The contractor will be responsible for advocating this Program and communicating 
this opportunity to the scientific community, soliciting proposals, and evaluating potential 
testbeds consistent with the selection criteria and Program objectives. In communicating the 
opportunity to submit proposals for subcontracts, the contractor will provide information 
concerning candidate testbed experiments, and solicit additional testbeds as part of such 
proposals. The contractor shall submit recommendations for award of subcontracts to the 
SAIS Program Manager and Program Scientist, who will approve the testbed teams. These 
telescience testbed teams will be selected from institutions such as those represented on 

the TFSUSS, and shall represent a cross-section of the NASA space science disciplines. 

The testbed experiments shall be performed in an environment that will enable scientists to 
develop and evaluate new multi-media telecommunications and information system 
technologies as they relate to actual scientific research functional requirements. The 
contractor will develop a management plan for the conduct of these testbeds and submit it to 
the SAIS Program Manager and Program Scientist for approval prior to awarding 
subcontracts. 

c. The Contractor shall award and administer, according to the submitted management 
plan, subcontracts to the University teams who will carry out the collaborative testbed 
experiments. 

d. The Contractor shall establish needed contact between testbed teams and experts 
in state-of-the-art computer science, telecommunications, networking, automation, robotics, 
and other relevant technologies, so that testbed teams can work with these experts in the 
design, conduct and evaluation of the experiments. The Contractor shall ensure that the 
teams develop meaningful experience working with network communications between 
heterogeneous computers, supercomputers, databases and scientific workstations 
emphasizing distributed scientific user access. 
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e. The Contractor shall assist in developing meaningful working relations between the 
Working Group and the Space Station Information System design teams to exchange 
information, examine problems, evaluate options, set priorities, and review progress towards 
the capabilities desired by the OSSA community. 

f. The Contractor shall provide assistance to the testbed teams in the installation and 
use of state-of-the-art computing and telecommunications technologies. 

g. The Contractor shall ensure that all important system developments within any of 
the testbed teams is shared with the other teams. 

h. The Contractor shall collect, assess, and synthesize final results of the various 
testbed experiments in order to make final recommendations to NASA on how Space Station 
can accommodate telescience. Based on the testbed results, dealings with Space Station 
hardware development teams, and interaction with related equipment and systems 
developers, the Contractor’s final report shall provide recommendations to the OSSA on the 
conduct and structure for the continuation of the testbed development program. 

i. The Contractor shall deliver the following items to the SAIS Program Manager and 
Program Scientist: 

Item Description Schedule 

(1) Management Plan for conducting 
the Testbed Program 

(2) Status reports on technical 
achievements of the testbed and 
problems encountered related to 
on-going activities. 

(3) Working Group meeting 
documentation with minutes and 
action items. 

(4) Interim Testbed recommendations 
for follow on NASA activities and 
directions for on-going program. 

(5) Recommendations on organizational 9 months 

and technical interfaces with Space 
Station Program activities to be 
pursued in the follow-on program. 

(6) Draft final report which will include 1 1 months 

a summary of Program accomplishments 
and recommended follow-on activities 
along with the justification for each. 

(7) Final report and Follow-on Program 12 months 

Plan. 


Prior to award of subcontracts, 
no later than 30 days after 
award of this contract. 

Quarterly 


2-3 month intervals 


6 months 
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Appendix D 

Subcontracts Acquisition Plan 

The following is the plan for selecting the University participants in the USRA 
Telescience Testbed Pilot Program, being funded by OSSA. 

Announcement of Opportunity 

An Announcement of Opportunity (AO) is attached (see Attachment 1) stating the 
objectives and nature of the program and how to submit proposals. This AO calls for short 
proposals describing the nature of the proposed experiments and answers to a number of 
specific questions, such as the issues to be resolved and the telecommunication 
requirements, as well as experience and background. The AO will be released at the earlier 
of 6 May 1987 or approval by NASA. The AO will be distributed to the eleven universities 
mentioned in the USRA proposal along with certain other selected organizations which have 
demonstrated through prior conversations and efforts their background, experience, and 
preparation to carry out an initial productive effort. These universities (both the original 
eleven and any additional organizations) have been selected by USRA because of their 
experience and expertise appropriate to the telescience investigations. This selection (and 
the selection of USRA as prime contractor) was made based on USRA’s experience and 
familiarity with the university space science community. Attachment 2 lists the proposed 
initial distribution list. 

Proposals are to be submitted to USRA by 27 May 1987. To facilitate review, 
advanced copies submitted electronically will be encouraged. 

Proposal Review Group 

A Proposal Review Group (PRG) is established to conduct peer review of the 
proposals. The PRG is intended to advise USRA in the selection of proposals to be funded, 
and is chaired by the USRA Program Manager. Members of the PRG are nominated by 
USRA and approved by NASA. Approval/disapproval shall take place within five days of 
submission. No response after seven days shall be taken to signify approval of the proposed 
PRG membership. 

Members of the PRG are selected to represent technological and discipline expertise. 
The NASA Program Manager and Program Scientist will sit on the PRG to facilitate 
discussion and understanding. The proposed members of the PRG are listed in Attachment 3. 

USRA Proposal Selection 

A meeting of the PRG will be held approximately 1 June 1987 to review the proposals 
received. Based on that review, the USRA Program Manager will select a set of proposals 
to be funded, subject to approval by NASA. This list, with the proposals, will be forwarded 
to NASA for approval, NLT five days after the PRG review. 
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NASA Approval 

Approval by NASA will be required before award of any subcontract. This approval 
shall take place within five days after receipt of the list of selected proposals from USRA. 
No response within ten days shall be taken to signify approval of the list. 

Subcontract Award 

Simultaneously with submitting the list of selected proposals to NASA for approval, 
USRA will begin the negotiation process with the selected Universities. Once approval by 
NASA has been received by USRA, the subcontracts will be awarded as rapidly as possible. 
It is anticipated that this negotiation process will be completed within two weeks after 
approval. 
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Announcement of Opportunity 


Background 

Space Station and its associated instruments and laboratories, coupled with the 
availability of new computing and information system capabilities, have the potential of 
significantly enhancing scientific research. To assure that this potential is met, scientists 
and managers associated with the Space Station project must gain significant experience 
with the use of these technologies for scientific research, and this experience must be fed 
into the development process for the Space Station Program. 

In its March 1986 Summer Study Report, the Task Force for Scientific Uses of the 
Space Station (TFSUSS) recommended that NASA initiate a program where university 
researchers would conduct rapid prototyping testbeds employing new telescience 
technologies and ideas. From this program would emerge additional and modified functional 
requirements for the Space Station Information System (SSIS). These testbeds would be 
specific research experiments within the scientific discipline areas that will use the Space 
Station complex. The experiments would be carried out in a coordinated manner to allow the 
critical questions to be answered by groups of scientists working with technologists in a 
rapid prototyping testbed environment. 

The rapid prototyping testbeds are not like other more typical testbeds. Rather than 
being used to evaluate and integrate systems on the way to deployment, the telescience 
testbeds constitute a Technology Evaluation Environment (TEE), allowing users to interact 
with advanced technologies in the conduct of scientific research in order to develop the 
required base of experience to permit development and evaluation of requirements and 
specifications. 

Program Description 

The Telescience Testbed Pilot Program, being performed by the Universities Space 
Research Association under contract to the Office of Space Science and Applications 
(OSSA), is the first step towards establishment of a TEE. It is intended to establish a 
university based group of SSIS users which will conduct several scientific experiments using 
advanced information processing and communications technologies. The results will then be 
evaluated to determine the technological and operational feasibility of requirements and their 
relative priorities in support of telescience. This will provide quantitative evidence as to the 
relative importance of different functions in the SSIS and their required performance. 
Furthermore, it will allow a set of scientific users to gain experience with advanced 
technologies and their application to science. The latter will result in a scientific community 
able to intelligently contribute to NASA’s review of SSIS requirements and proposed design 
prior to development of Space Station hardware. 

To assure that the critical questions and issues are being addressed in the Pilot 
Program, a Telescience Testbed Working Group (TTWG) will be formed. The IT WG will 
consist of representatives of the various participating universities as well as certain other 
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selected organizations developing relevant technologies. The TTWG will meet roughly three 
times during the program to review and coordinate the testbed activities. The TTWG will 
also assist in the planning for the follow-on NASA program. 

USRA has been funded to coordinate and manage this pilot program. Subcontracts will 
be issued to several universities to carry out experiments in different aspects of telescience. 
These subcontracts will be based on proposals received in response to this Announcement of 
Opportunity. Proposals will be selected by USRA and NASA based on recommendations by 
an independent Proposal Review Group. Funding availability and the quality of the received 
proposals will determine the exact number and funding level of the approved proposals. At 
this time, it is anticipated that roughly 10-15 proposals will be funded at levels between 
$50K (for initial activities) and S250K (for significant augmentations of ongoing relevant 
research.) 

Submission of Proposals 

Ten copies of proposals, not to exceed ten pages in length describing the technical 
program, should be sent to the USRA Program Manager (listed below). Proposals should be 
submitted by 27 May 1987. To facilitate the proposal review process, submission of 
advanced copies of the proposal by electronic mail to the USRA Program Manager is 
encouraged. The proposals should contain the following items: 

• A description of the experiments to be performed. The technologies to be used 
and evaluated in performing the experiments. 

• A discussion of the questions and issues to be resolved through the conduct of 
the experiment. 

• A discussion of the importance of doing the work being proposed. 

• A discussion of ongoing relevant efforts. 

• A description of the current computer networking technology available and the 
required enhancements. 

• A discussion of the other organizations (NASA, university, or other) 
participating or collaborating in the experiment. 

• A proposed budget, which should address funding for the proposed research 
itself, the required computing and communications infrastructure, travel for 
attending meetings of the TTWG (anticipated to be on the West Coast), and 
any necessary travel for the proposed research activity. Any cost-sharing or 
required Government Furnished Equipment (GFE) shall be clearly identified. 
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The following are the tentative evaluation criteria to be used in evaluating the 
proposals: 

Consistency of Objectives 

Alignment of the objectives of the proposed testbed with the general objectives of the 
overall Science Applications Information System (SAIS) program. 

Adherence to Concept 

Adherence to the testbed concept of rapid prototyping for the determination of 
telescience applicability. 

Increased Operability 

Degree to which the testbed can contribute to an improved mode of user operations and 
scientific productivity making non-relevant technical issues transparent and with an 
improved user interface which allows the Scientist to concentrate on strictly scientific issues. 

Increased E iciency 

Degree to which the testbed contributes to an improvement in a more efficient use of 
human and system resources. Increased efficiency in the use of system capabilities can 
lower overall ops costs and increase the overall system productivity 

Expanded Capability 

Degree to which the testbed can contribute to increased functionality of the end-to-end 
information system. New scientific and technological capabilities can contribute to the 
support of new or improved scientific methods. These in turn can improve the quality of the 
science process and improve system productivity. 

Demonstrate Technical Effectiveness 

Degree to which the testbed can demonstrate and assess the applicability and 
effectiveness of the proposed technical approach. 

Effective Usage of Resources 

Degree to which the testbed makes effective use of available and potential resources or 
integrates commercially available resources in a cost effective manner. 

Ability to Promote Usage of Results 

Degree to which the testbed proposal can promote the use of the testbed results in the 
development of, or transition to, the operational system. 
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Relationship to On-going Programs 

Degree to which the testbed relates to the on-going program and its participants. A 
coherent testbed program will improve the effectiveness of the resources employed and 
promote the exchange of information among projects. 

Cost Effectiveness and Financial Expediency 

Testbed projects must be cost effective and financially expedient commensurate with 
their proposed benefits. 

Potential for Future Cost Savings 

Potential for future cost savings resulting from more efficient use of technical and human 
resources. 

Uniform Applicability 

The ability of the resultant application to address multi-disciplinary concerns or to have 
a high potential for universal applicability. Ability to increase interactions among scientific 
disciplines. 

Potential for Increased Responsiveness to User Needs 

Ability of testbed result to increase the overall functionality of the operational system 
in meeting user needs and perceived requirements. 

Ability of Proposer to Accomplish Work 

Ability of institution and institutional resources to accomplish what has been proposed 
and also their ability to build on what they start. 

Further Information 

For more information on the technical aspects of the program, contact the USRA 
Program Manager: 

Dr. Barry M. Leiner 
Senior Research Scientist 

Research Institute for Advanced Computer Science 
NASA Ames, MS 230-5 
Moffett Field, CA 94035 

(415) 694-6362 

Arpanet: Leiner@RIACS.EDU 
Telemail: B Leiner 

Foe information concerning administrative aspects, contact: 
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Mr. David Holdridge 

Universities Space Research Association 

Suite 201 W 

600 Maryland Avenue, SW 
Washington, DC 20024 

(202) 479-2609 

Arpanet: DHoldridge%telemail@Ames.ARPA 
Telemail: DHoldridge 
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Attachment 2 
AO Distribution List 
Massachusetts Institute of Technology 
Purdue University 
Rensselaer Polytechnic Institute 
Smithsonian Institution Astrophysical Observatory 
Stanford University 
University of Arizona 
University of California, Berkeley 
University of California, Santa Barbara 
University of Colorado 
University of Maryland 
University of Michigan 
University of Rhode Island 
University of Wisconsin 
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Attachment 3 

Proposed PRG Membership 

Richard desJardins CTA 


Ralph Kahn 

Barry Leiner (chairman) 
Daryl Rasmussen 
Erwin Schmerling 
Peter Shames 
Jim Weiss 
Denny Xenofos 


University of Washington 

RIACS 

NASA ARC 

NASA HQ 

STScI 

NASA HQ 

NASA MSFC 
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Glossary 


AAS 

AGO 

AIPS 

ALOT 

Andrew 

ARC 

ARPANET 

AT 

ATF 

Athena 

AVHRR 

B&W 

BARRNET 

BAUD 

BCE 

BDCF 

CAS 

CCD 

CCSDS 

CDP 

CLIPS 

CODEC 

CSDF 

cui 

DARPA 

DEC 

DMIL 

DOC 

DSP 

EPS 

EUV 

EUVE 


American Astronomical Society 
Automatic Gain Control 
Astronomical Image Processing System 
Arc Laser Optical Technology 

Multimedia mail system; basis of Camegie-MeUon EXPRES system 
Ames Research Center 

Wide area data network supported by DARPA 
Astrometric Telescope 
Astrometric Telescope Facility 
MIT student network 

Advanced Very High Resolution Radiometer; on the nimbus series of 
satellites. Operated by NOAA 

Black and White Display 

Bay Area Regional Research Network 

A unit of signaling speed; refers to the number of times the state or 
condition of the line changes per second 

Bench Checkout Equipment 

Baseline Data Collection Facility (at KSC) 

Canadian Astronomical Society 

Charge Couple Device; a technology for converting images into 
electrical signals 

Consultative Committee for Space Data Systems 

Command, Data, and Power interface unit; part of the EUVE instrument 

A programming language for expert systems.. 

Coder/Decoder 

Commercial Space Development Facility 

Common User Interface 

Defense Advanced Research Projects Agency 

Digital Equipment Corporation 

Direct Manipulation Interface Language 

Discipline Operations Center 

Digital Signal Processing 

Experiment Payload Specialist 

Extreme Ultraviolet 

Extreme Ultraviolet Explorer 
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EXPRES 

FUV 

FRICC 

GOES 

GPX 

GSFC 

HCIG 

HIPS 

HRPT 

HUP 

IBM 

ICD 

IDL 

IGBP 

IL 

IMS 

Ingres 

IOMS 

IPAC 

IRAF 

ERAS 

JPL 

JSC 

JVNCC 

KSC 

Kermit 

Kiwi 

LAN 

LASP 

LCC 

LIBSTPARSE 

LSTB 

Magic/L 

McEDAS 

MIT 

MMSL 

MMT 

MSFC 


Experimental Program in Electronic Submission 
Far Ultraviolet 

Federal Research Internet Coordinating Committee 
Geostationary Operational Environmental Satellite 
Graphics Processor Workstation for microVAX II 
Goddard Space Flight Center 
Human-Computer Interface Guide 

Human Information Processing Laboratory’s Image Processing 

High Resolution Picture Transmission 

Human Use Protocols 

Intemadonal Business Machines 

Interface Control Document 

Interactive Data Language 

International Geosphere Biosphere Program 

Intermediate Language 

Instrument Management Services 

A database 

Instrument OMS 

Infrared Processing and Analysis Center at Caltech 

Image Reduction and Analysis Facility 

Infrared Astronomy Satellite 

Jet Propulsion Laboratory 

Johnson Space Center 

John Van Neuman Computing Center 

Kennedy Space Center 

A file transfer program 

A “flightless bird” consisting of prototype EUVE electronics 
Local Area Network 

Laboratory for Atmospheric and Space Physics 
Local Controlling Computer 

VAX/VMS library routine that provides a table driven parser. Used for 
the initial version of the CSTOL parser for OASIS 

Life Sciences Testbed 

Interactive programming language developed by Loki Engineering, Inc 

Man Computer Interactive Data Access System 

Massachusetts Institute of Technology 

Microgravity Materials Science Laboratory 

Multiple Mirror Telescope on Mt. Hopkins, AZ 

Marshall Space Flight Center 
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NASA 

National Aeronautics and Space Administration 

NASA SELECT 

NASA operated TV channel which carries NASA related events 

NASCOM 

NASA Communications- mission critical 

NFS 

Network File System 

NICOLAS 

The inter-network gateway at Goddard Space Flight Center 

NOAA 

National Oceanic and Atmospheric Administration 

NOAA-G 

Name of the NOAA polar orbiting satellites 

NRAO 

National Radio Astronomy Observatory 

NSE - 

Network Software Environment 

NSF 

National Science Foundation 

NSFnet 

Computer network supported by NSF 

NSI 

NASA Science Internet 

NSN 

NASA Science Network; TCP/IP part of NSI 

NTSC 

Standard video signal format 

OASIS 

Operations and Science Instrument Support 

OMS 

Space Station Operation Management System 

OMS/PMS 

Operations Management/Platform Management System 

OMSS 

Operation Management System Services 

OSSA 

Office of Space Science and Applications 

PI 

Principal Investigator 

PSI 

Payload Systems, Inc. 

RA 

Research Assistant 

RCC 

Remote Commanding Computer 

RFH 

Remote Fluid Handling 

RGB 

Red, Green, Blue Video Display 

RIACS 

Research Institute for Advanced Computer Science 

ROM 

Read Only Memory 

RS-232 

Standard for serial data transmission 

SAIS 

Science and Applications Information Systems 

SAO 

Smithsonian Astrophysical Observatory 

SCS 

Software Control System 

SIMBAD 

A cross-referenced database of 700,000 stellar and 100,000 non-stellar 
objects 

SESAC 

Space and Earth Sciences Advisory Committee 

SFDU 

Standard Formatted Data Unit 

SME 

Solar Mesosphere Explorer satellite 

SOP 

Science Operations Subgroup 

SPAN 

Space Physics Analysis Network 
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SPIE 

Society of Photo-Instrumentation Engineers 

ss 

Space Station 

SSE 

Software Support Environment 

SSIS 

Space Station Information Systems 

SSL 

Space Sciences Laboratory at UC, Berkeley 

SSP 

Space Station Program 

STScI 

Space Telescope Science Institute 

TAE 

Transportable Applications Executive 

TATS 

Thaw Atmospheric Telescope Simulation 

TCP/IP 

Transmission Control Protocol/Intemet Protocol 

TDRSS 

Tracking and Data Relay Satellite System 

TeleWEn 

Telescience Workstation Environment 

Terracom 

A company name 

TFSUSS 

Task Force on Scientific Uses of Space Station 

TIF 

Telescope Interface Unit 

TIGS 

Testbed at LASP 

TMIS 

Technical Management Information System 

TTPP 

Telescience Testbed Pilot Program 

UC 

University of California 

UCB 

University of California, Berkeley 

UCSB 

University of California, Santa Barbara 

UIL 

User Interface Language 

Unify 

A database program 

UofA 

University of Arizona 

USE 

User Support Environment 

USRA 

Universities Space Research Association 

uw 

University of Wisconsin 

VISTA 

another image processing system 

WAN 

Wide Area Network 

ZOE 

Zone of exclusion 
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A 

access 0-3, D-6, D-14, 0-23, 0-24, 0-31, 0-37, 
0-46, 0-57, 0-62, 0-63 
Ada 0-7,0-42,0-45,0-56 
ADS 0-25 
AI 0-45 

AIPS 0-5,0-26,0-29 
American Astronomical Society 0-29 
Ames Research Center, see ARC 
Analysis 0-55 

Announcement of Opportunity 0-17,0-95,0-98 
ARC 0-7, 0-8, 0-12, 0-14, 0-15, 0-26, 0-38, 
0-42, 0-44, 0-49, 0-50, 0-78 
Arizona 0-4, 0-5, 0-7, 0-12, 0-13, 0-14, 0-15, 
0-16, 0-21, 0-22, 0-23, 0-25, 0-26, 0- 
35, 0-39, 0-40, 0-42, 0-43, 0-44, 0-45, 
0-47, 0-49, 0-50, 0-65, 0-76 
ARPAnet 0-46 
artificial intelligence 0-27 
ASTIS 0-29 

Astrometric T elescope Facility 0-13 

astronomy 0-4,0-13,0-21 

astrophysics 0-4,0-12,0-21,0-60 

Astrophysics Data Systems 0-25 

ASYST 0-49 

Athena 0- 1 2, 0-23 , 0-26 

audio 0-7, 0-38, 0-39, 0-50, 0-61, 0-64, 0-65 

autonomous 0-15 

B 

bandwidth 0-5,0-32,0-39,0-41,0-60 
BCDF 0-51 

Berkeley 0-4, 0-12, 0-13, 0-21, 0-77 

Bitnet 0-3 1 

browse 0-25 

browsing 0-16 

bulletin board 0-72 

c 

C 0-23,0-41 
CalTech 0-12,0-79 
Calibration 0-63 

California Institute of Technology, see Cal Tech 
campaign experiments 0-6,0-9,0-14 
catalog 0-6, 0-32, 0-57 
CCD 0-5,0-25,0-44 
CCD occuladon 0-23 


CCSDS 0-7,0-46,0-48 
coaching 0-3, 0-7, 0-16, 0-33, 0-36, 0-38, 0- 
40, 0-43, 0-57, 0-62, 0-64 
Colorado 0-5, 0-7, 0-12, 0-13, 0-14, 0-15, 0- 
16, 0-21, 0-22, 0-23, 0-30, 0-34, 0-35, 
0-39, 0-41, 0-42, 0-45, 0-47, 0-49, 0- 
50, 0-63, 0-77 

command interlocking 0-48, 0-62 
communications 0-3, 0-5, 0-14, 0-40, 0-60 
compression 0-5, 0-7, 0-32, 0-34, 0-39, 0-57, 
0-65 

Connectivity 0-61 
Contract 0-66 
Coordination 0-18, 0-7 1 
Cornell 0-12,0-13,0-21,0-26,0-75 
crew 0-3, 0-6, 0-14, 0-38, 0-40, 0-42, 0-48, 0- 
50,0-61,0-64 

D 

Data Compression 0-24 
Data Interchange 0-46 
data rates 0-24 
data reduction 0-12 
data transfer 0-14 

database 0-6, 0-32, 0-37, 0-53, 0-55 
datasets 0-16 
debugging 0-2, 0-55 
DECnet 0-45 

delay 0-5, 0-6, 0-7, 0-14, 0-24, 0-30, 0-34, 0- 
40, 0-44, 0-45, 0-60, 0-65 
Design 0-52, 0-55 

directory 0-6, 0-28, 0-32, 0-33, 0-34, 0-57 
Distribution 0-28 
DOC 0-51 

documentation 0-25, 0-27, 0-33, 0-53, 0-55 
Downlink 0-61 
dropouts 0-8, 0-44, 0-52 

E 

E-Mail 0-47 
E-mail 0-31,0-52 
e-mail 0-33 

Earth Science and Applications Data System 0-25 

Earth Sciences 0-13, 0-32 

earth sciences 0-5, 0-60 

Education 0-23 

Einstein 0-26 

Electronic 0-26 

Electronic Mail 0-28 

Electronic mail 0-18,0-26,0-71 

electronic mail 0-5, 0-6, 0-8, 0-9, 0-16, 0-64 

Equipment Procurement 0-68 
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error checking II- 8 
ESADS H-25 
EUVE n-13,n-23 
Expert System 11-36 
Expert Systems 11-45 

F 

Fabry-Perot Spectrometer 11-14 
Facilities 11-69 
FAX n-55 

Field Campaigns 13-69 
File transfer 13-3 1 

file transfer H-3, H-6, H-34, 11-57, 11-64, 11-72 

file transfers H-34 

FITS n-5, n-26, fi-29 

fluid handling 11-15, 11-16, 11-44, fl-50 

formats 13-6, 11-55, 13-57 

Funding 11-68 

G 

GKS fl-29 

glovebox II- 15, 11-44, 11-56 

Goddard Space Flight Center, see GSFC 

GPX fl-49 

graphics 11-64 

GSFC II- 12,11- 13,11-16 

H 

HDTV D-65 
HST n-30 
HyperCard 11-50 

I 

ICD H-45 
image 11-33 

images H-6, fl-25, H-34, fl-43, H-65 
Infrared Analysis and Processing Center 11-26 
Infrastructure II-3 
Instruments 11-23 
Interconnection n-24 
interface control documents H-45 
interface specifications documents 11-55 
interfaces H-45 

Internet H-5, H-6, 11-23, 11-29, 11-31, H-34, II- 
57, H-72 
IPAC n-26 
IR array 11-23 
IRAF D-5, n-26, H-29 
ISDN H-57 
IUE n-26 


J 

Jet Propulsion Laboratory, see JPL 
Johnson Space Center, see JSC 

jpl n-i2.n-i3.n-i5 

jsc n-8,n-i4,n-i6,n-45,n-47,n-79 

K 

Kennedy Space Center, see KSC 
Knowledge Capture n-50 
ksc n-i4, n-i5, n-40, n-4i, n- 43 , n-44, n-45, 
n- 47 , n-48, n- 49 , n-50, n -79 

L 

Lab VIEW n-41 

LabView H-55 

LANS n-23 

LANs n-46 

Latency 11-61 

latency H-4, H-5 

LeRC n-15,H-79 

Lewis Research Center, see LeRC 

Life Sciences H-14, H-35 

life sciences H-6, H-60 

Life Sciences Data Distribution System 11-47 

M 

Macintosh H-8, H-38, H-41, H-49, n-50 

mailing lists H-9, H-18, H-72 

Manipulation H-36 

Maryland H-21, H-77 

Massachusetts Institute of Technology n-21 

Massachusetts Institute of Technology, see MIT 

Materials Science n-15 

McIDAS n-32 

Mcldas H-14 

Meridian Ada H-49 

Michigan fl-13, H-14, H-15, H-16, H-78 

Microgravity Sciences 11-15, H-51 

microgravity sciences H-60 

microVAX H-3, H-29, H-41, H-49 

microVAXes fl-59 

mu n-4, n-7, n-8, n- 12 , n- 14 , n- 15 , n- 22 , n- 
23 , n- 25 , n-26, n- 35 , n- 39 , n- 40 , n-4i, 
n- 43 , n- 44 , n- 45 , n- 47 , n-48, n- 49 , n- 
50, n-75 
mock-up H-38 
modems H-34 
monitor H-61 
Monitoring n-36, H-39 
monitoring H-6, H-39, n-53, H-65 
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MSFC H-16 
Mt. Hopkins 13-13,11-22 
Multimedia 11-55 
multimedia 11-64 

N 

NASA Science Internet 11-46 

NAS Am ail 11-72 

NASAselect 11-55 

NASCOM H-46 

NETWORK fl-31 

Network H-30, 11-34, H-45, H-64 

network H-4, H-6, II-8, H-13, n-16, H-33 

Networks 11-26, 11-38 

networks 11-25, 11-66 

NFS D-29 

NSFnet H-14, n-46 

NSI n-46 

NSN H-31 

NSSDC fl-32 

O 

oasis n-6, n-7, n- 1 6 , 11 - 32 , n- 42 , n- 49 , n-5 1 , 
n-53, n-60 

Observation 11-36 
observatory 11-13, H-16 
occultation 11-25 
open mike 11-40 
Operations 11-35, 11-43, 11-62 
operations 11-12 

Operations Management 11-48, 11-52 
Operations management n-7 
OSI H-46 

P 

packet switching n-4 
Parallax H-48 
Participants n-75 
Payload Systems, Inc. H-75 
PDS H-25 
Phasing H-61 

pi n-3, n-7, n-i4, n-38, n-40, n-48, n-50, n- 
61,n-64 

Planetary Data System H-25 
Planning H-62 
precision H-22 
PRG n-95,n-104 
Principal Investigator H-36 
Productivity H-22, H-50, H-51, H-63 
productivity H-4, H-8 
Program H-55 


Programmatic H-66 
Programmatics n-26 
programmatics H-8 
Project Definition Document 11-47 
Proposal H-27 

Proposal Review Group U-18, n-95 
Prototyping n-70 
prototyping H-50, H-55, H-56 
Purdue H-6, H-13, H-14, H-34, n-75 

Q 

quad splitter H-49 

R 

rates n-4, H-7, H-34, H-40, H-43, H-44, 11-45, D- 
52, U-65, H-66 
Reliability H-44, H-52 
reliability H-30, H-66 
Remote coaching H-53 
remote coaching H-60 
Remote login H-31 
remote login H-23 
remote observing 11-2 1 
Rensselaer Polytechnic Institute, see RPI 
reports n-8, U-67 

Research Institute for Advanced Computer Science, 
see RIACS 

resource management H-12 
RFP H-17 
Rhode Island H-7 8 

riacs n- 1 5, n- 1 6, n-26, n- 72 , n-78 

robot H-44, n-52, H-56 

robotics n-16 

robots E-43 

Robust H-24 

Rochester H-79 

rpi n-8, n-i5,n-65,n-76 

s 

Safety H-24 
safety H-7 

Santa Barbara H-6, H-13, H-14, H-15, H-16, H-77 

sao n-3, n-4, n-5, n-13, n-22, n-23, n-24, n- 
26, n-76 
scheduled H-41 

Scheduling H-33, H-35, H-38, D-52, n-62 

scheduling n*64 

Scorbase H-49 

Security H-32 

SFDU H-7, H-46 

Simulation H-38 
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simulation 11-39, 11-56 
SIRTF H-13, n-26, H-78 
Skylab 0-35 * 

Smithsonian Astrophysical Observatory, see SAO 

Smithsonian Astrophysics Observatory 0-21 

Software 0-41,0-45,0-49 

software 0-5, 0-23 

Solar Mesosphere Explorer 0-14 

Space Infrared Telescope Facility, see SIRTF 

Spacelab 0-35 

Spacelab 2 0- 16 

SPAN 0-5,0-6,0-8,0-31,0-34,0-45 
SSIS 0-64 

Standard Formatted Data Unit 0-46 
standardization 0-50, 0-60 
Standards H-29, 0-45, 0-59 
standards 0-4, 0-5, 0-6, 0-7, 0-14, 0-25, 0-32, 
0-41,0-51,0-55,0-57 
Stanford 0-14, 0-15, 0-16, 0-35, 0-50, 0-76 
Statement of Work 0-91 
Steward Observatory 0-21 
STScI 0-29,0-30 
Sun 0-3,0-29,0-49,0-59 
systems engineering 0-67 

T 

TAE+ 0-4,0-7,0-56,0-60 
TCP 0-57 

TCP/IP 0-29,0-31,0-46 
TDRSS 0-35,0-43 
technology transfer 0-67 
Teleanalysis 0-25, 0-32, 0-65 
teleanalysis 0-3,0-5,0-14, 0-2 1,0-56 
teleconference Q-56 
teleconferencing 0-4 
Teledesign 0-33 
teledesign 0-2, 0-5, 0-13 
Telemanagement 0-64 
telemetry 0-47, 0-65 
Teleoperation 0-22 
Teleoperations 0-51,0-58,0-65 
teleoperations 0-2, 0-4, 0-6, 0-8, 0-13, 0-14, 
0-16,0-30,0-40,0-46 
telerobotics 0- 14 
telescope 0-5,0-13 
TFSUSS 0-1,0-17,0-91 
throughput 0-33 
Training 0-38 
training 0-62 

Training and Documentation 0-48 
TV 0-7,0-42,0-44,0-49 


u 

UCB, see Berkeley 

UCSB 0-34 

UCSB, see Santa Barbara 

Universities Space Research Association, see USRA 

UNIX 0-23,0-59 

Unix 0-3,0-29,0-41 

UOF 0-51 

Uplink 0-62 

User Interface 0-50, 0-53 

user interface 0-4, 0-23, 0-56, 0-57, 0-59 

USRA 0-78 

V 

Video 0-40,0-43,0-52,0-61 
video 0-7, 0-21, 0-24, 0-30, 0-38, 0-39, 0-42, 
0-43, 0-48, 0-49, 0-50, 0-55, 0-60, 0- 
64, 0-65 

VMS 0-3,0-29,0-59 
Voice 0-52 

voice 0-21,0-30,0-40,0-52,0-64 

w 

Wallace Observatory 0-12 
Wisconsin 0-6, 0-13, 0-14, 0-32, 0-78 
Workstation 0-48, 0-59 
workstation 0-2, 0-3, 0-8, 0- 16, 0-23, 0-33, 0- 
41 

workstations 0-25, 0-50, 0-55 

X 

X 0-23,0-29,0-41,0-49,0-57 
X- windows 0-8 

z 

Z.O.E. 0-52 

zone of exclusion 0-61 
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Universities Space Research Association 
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Columbia, MD 21044 
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